Bluesky character counter

Text has at least four lengths, and different tools report different ones. A grapheme is what a reader sees as one character. A code point is one Unicode character number. JavaScript's .length counts UTF-16 code units, where characters outside the basic range take two. Bytes are the size of the text in UTF-8, the encoding Bluesky stores. These numbers come from running the counter's own functions:

• "hello": 5 graphemes, 5 code points, 5 UTF-16 units, 5 bytes.
• "café" typed as one é: 4 graphemes, 4 code points, 4 units, 5 bytes.
• "café" typed as e plus a combining accent: still 4 graphemes, but 5 code points, 5 units, 6 bytes.
• "👍🏽" (thumbs-up with skin tone): 1 grapheme, 2 code points, 4 units, 8 bytes.
• "👨‍👩‍👧‍👦" (family): 1 grapheme, 7 code points, 11 units, 25 bytes.
• "🇺🇸" (a flag): 1 grapheme, 2 code points, 4 units, 8 bytes.
• "日本語": 3 graphemes, 3 code points, 3 units, 9 bytes.
• "𝗕𝗼𝗹𝗱" (Unicode bold): 4 graphemes, 4 code points, 8 units, 16 bytes.

The post record's text field in Bluesky's app.bsky.feed.post lexicon has maxGraphemes: 300 and maxLength: 3000, where the length is in bytes. A post has to satisfy both. For most writing, the grapheme limit is the one you hit: 300 plain Latin letters are 300 bytes, and 300 Japanese characters are 900 bytes, both well under 3,000.

Emoji are where bytes catch up. A family emoji is 1 grapheme but 25 bytes, so 120 of them reach 3,000 bytes while using only 120 of the 300 graphemes. Three hundred of them would be 7,500 bytes. If a post is mostly emoji or flags, watch the byte meter rather than the grapheme one.

Bluesky's 300 is higher than X's 280, and the units differ. The sample in the box, "Family update 👨‍👩‍👧‍👦 counts as one grapheme on Bluesky.", is 50 graphemes and 74 bytes here, and weighs 51 in the X character counter. More on the rules in our Bluesky character limit guide.

A Bluesky post stores links, @mentions and hashtags separately from the text, as facets. Each facet points at a slice of the text by byte offsets. The facet lexicon puts it directly: indices count "bytes of the UTF-8 encoded text", and languages like JavaScript that index strings by UTF-16 or code points need to convert before working with facets. An off-by-a-few offset is the classic bug in hand-written Bluesky clients when the text contains emoji or accented letters.

Unlike X, Bluesky doesn't give links a fixed weight. A URL you put in the text counts its full length, as written, toward 300 graphemes: "https://example.com/docs/webhooks" is 33 graphemes on Bluesky and 23 on X. Long tracking links are expensive here, so trim query strings you don't need.

When you post through our Bluesky API, facets are detected automatically from the text with the official @atproto/api library (RichText.detectFacets), so links, mentions and hashtags come out clickable without you computing byte offsets.

Bluesky posts can carry up to 4 images, each up to 2,000,000 bytes, per the app.bsky.embed.images lexicon. Every image object has a required alt field, described there as "Alt text description of the image, for accessibility". The lexicon requires the field but allows it to be an empty string, so an image can be posted with no description at all.

Write one anyway. Alt text is what screen reader users get in place of the image, and it doesn't count toward the 300 graphemes of the post text. In our API, pass it as alt on each media item; if you leave it out we send an empty string, which is valid but tells a screen reader user nothing.

{
  "accounts": ["acc_..."],
  "text": "New docs for webhooks are up.",
  "media": [{ "url": "https://example.com/webhooks-diagram.png", "alt": "Diagram: a post is published, then a signed webhook is sent to your server." }]
}

Bluesky is one of the five networks live on our API. Before anything is sent, our preflight check counts the text in graphemes, the same function this counter uses. Over 300, the request fails with HTTP 422, preflight_failed, and a text_too_long issue that says how much to cut. Nothing is published to any account in the request. Send dry_run: true to run the checks without posting.

The check covers both limits. A post under 300 graphemes but over 3,000 bytes, which takes a lot of emoji, also fails with text_too_long, and the message gives the byte count. The byte meter above shows the same number as you type.

{
  "error": {
    "code": "preflight_failed",
    "message": "The post would fail on 1 check(s). Nothing was published.",
    "fix": "Fix the issues below, or send dry_run: true to iterate without publishing.",
    "issues": [{
      "account_id": "acc_...",
      "platform": "bluesky",
      "severity": "error",
      "code": "text_too_long",
      "field": "platform_options.bluesky.text",
      "message": "Text is 312 characters; Bluesky allows 300.",
      "fix": "Shorten it by 12+ characters, or set platform_options.bluesky.text to a shorter version."
    }]
  }
}

The same draft lands differently on each network: 300 graphemes on Bluesky, 280 weighted characters on X, 3,000 characters on LinkedIn. A post that fits Bluesky with a long link may be over on X once its emoji double, or under on X because its link shrinks to 23. Use platform_options to give a network its own version of the text when one draft can't fit all three. Our cross-posting guide walks through it, and the docs list every field.