Free Bluesky Share Link Generator

A Bluesky share link is a normal https URL that opens the Bluesky composer with a draft already typed. The address is https://bsky.app/intent/compose?text= followed by your URL-encoded message. Bluesky calls these intent links, the same idea as the classic tweet intent or the LinkedIn share URL. The person clicking it still reads the draft and presses Post themselves, nothing is published automatically.

A profile link asks the reader to do the work: open Bluesky, start a post, find your URL again, write something. A share link collapses all of that into one tap and lands them in a composer that already says what you want said. Fewer steps between the impulse and the post, and the wording of those shares stays consistent, which matters when you are trying to get a specific phrase or product name repeated.

Yes, but not at full length. The compose intent gives you exactly one usable parameter, text, so your link is part of the message body. Bluesky's own client trims link text before it counts it: toShortUrl in social-app drops the scheme and, once the path runs past 15 characters, keeps only its first 13 followed by an ellipsis. A URL therefore costs roughly your domain plus 16 characters. Apply that rule to the 72 character link https://www.example.com/blog/some-long-post-slug?utm_source=bluesky&i=1x and you get www.example.com/blog/some-lo..., which is 31 characters. Our counter reimplements that trimming rule before it counts, so it charges the link 31 too.

For counting and for the published post, yes. The official client measures a shortened copy of the draft, defined in social-app as "function getShortenedLength(rt: RichText) { return shortenLinks(rt).graphemeLength }", and that shortened length is what the composer's counter shows and what the Post button is gated on. The same shortenLinks call runs again when the post is created, so the text that goes into the record is the trimmed stub, while the complete URL is carried alongside it in the post's link facet so it still resolves. What Bluesky does not give you is a short address you can paste elsewhere, or any click data. The trimming lives in that client, so a post created straight through the AT Protocol API carries the text you send it, at its full length.

It works in both, with a caveat. On desktop the link opens bsky.app in the browser and drops the text straight into the composer. On mobile, iOS and Android hand bsky.app URLs to the installed Bluesky app through Universal Links and App Links, so the app composer opens with your draft. If the app is not installed, the mobile browser opens the web composer instead, and the text still arrives.

No, not from a share link on your site. Bluesky's docs list a single parameter: "The web URL endpoint is https://bsky.app/intent/compose, with the HTTP query parameter text." The app's intent handler also reads imageUris and videoUri, which are undocumented, but in the client source an image URI containing http:// or https:// is discarded and images are passed through on native builds only, which rules out pointing a web share button at a hosted image. If you need an image in the post, attach it manually after the composer opens, or publish through the AT Protocol API with your own client, which uploads the blob first and then creates the record.

Not with an intent link. A share link does nothing until a human clicks it, so there is no moment in time to schedule. Scheduling requires either a third party tool that holds an app password and posts on your behalf, or your own AT Protocol integration. Share links solve distribution, not timing.

They point in opposite directions. A share link sends people INTO Bluesky with a draft ready to publish, so it belongs on your website, in your newsletter, or at the end of a blog post. A shortened link sends people OUT of Bluesky to your destination, so it belongs inside your own posts and bio. Use our Bluesky link shortener for that second job, and use this generator for the first.

Bluesky counts graphemes, which is the technical term for what a human sees as one character, so a standard emoji counts as one and an accented letter counts as one. Our counter walks code points instead, which means a flag or a skin tone emoji can read as two here where Bluesky reads one. Leave a little headroom if your draft is full of those.

Neither. The generator builds a URL string in your browser, it never talks to Bluesky, and there is nothing to authenticate. You only need an account at the moment someone actually clicks the link and posts, and that account belongs to them, not to you. Nothing here touches the AT Protocol, app passwords, or OAuth.

Yes. Type them in the hashtags field without the hash symbol and we normalise and append them. Bluesky parses hashtags at post time and turns them into tappable facets, so they become real clickable tags in the published post. Two or three focused tags outperform a wall of them, and remember each one eats into the same 300 characters.

Bluesky shows the sign in screen first. Whether the draft survives the login round trip depends on the client and the session state, so treat a logged out click as a lower probability share. This is a good argument for putting the share button where your logged in Bluesky audience already is: your newsletter, your docs, your thank you page after a signup.

Not from Bluesky, which does not report intent clicks back to you. The workaround is to point your button at a Flyn short link that redirects to the bsky.app intent URL. Flyn counts the clicks, so you learn which page, newsletter, or docs section drives shares, and the composer still opens with your text intact.

No. Everything on this page is built with client side JavaScript. Your text, URL, and hashtags never leave the browser, and there is no server log of what you typed. Pressing Build does fire one product analytics event, and its payload is the tool name and the word generate, with nothing from your draft in it. Every successful Build is also saved to a history list in your browser localStorage, capped at the last twenty entries, which you can clear from the panel.

Almost always double encoding. The text parameter is already percent encoded, so a tool that helpfully encodes the whole href a second time turns %20 into %2520 and the composer fills with garbage. Paste the link exactly as generated, and if your email or CMS editor mangles it, use the HTML snippet we output instead of retyping the href.