Twitter (X) Bookmarklets: 6 Working Scripts for x.com in 2026

A bookmarklet is an ordinary bookmark whose address begins with javascript:. When you click it, the browser evaluates the code in the context of the page you are on, as if you had typed it into the developer console. That gives the code everything the page's own scripts have: location, document, navigator.clipboard, window.open. It is the oldest form of user script, and for one-off actions on a page it is still the simplest: no extension, no permissions dialog, no store.

Sites can restrict scripts with a Content-Security-Policy header, so we read x.com's. Fetching https://x.com/ with a plain HTTP client this session returned a long policy; the parts that matter for a bookmarklet are these.

Whether CSP applies to bookmarklets at all is a question the specification answers in the user's favor: the CSP Level 2 processing model (W3C, section 5) says user agents may let users modify or set aside policy enforcement through user preferences, bookmarklets and browser add-ons. In practice Chrome, Firefox and Safari run a javascript: bookmark on a CSP-protected page, and the policy then applies to whatever the bookmarklet tries to load or connect to. That is exactly the split you see above: your code runs, outside resources are filtered.

Two more design rules follow. First, keep everything self-contained: no import(), no script tags, no CDN. Second, when a bookmarklet needs a service, send the user to it in a new tab with the value on the clipboard or in the URL, rather than trying to call it from x.com. Bookmarklets 3 and 4 below do exactly that.

On precision. Tweet IDs are 64-bit integers; X's own documentation on IDs warns that JavaScript integers are limited to 53 bits, which "causes precision loss with large IDs". All 960 IDs in our sample were 19 digits long and above 2^53 - 1, and we confirmed the failure under Node: Number("2111180963661435219") evaluates to 2111180963661435100. Every bookmarklet here that touches the ID keeps it as a string or a BigInt.

The procedure is the same everywhere: create a bookmark, then replace its address with the one-line javascript: code. Browsers strip the javascript: prefix when you paste code into the address bar, which is a safety feature, so always install through the bookmark editor, never by pasting into the URL bar.

Chrome. Show the bookmarks bar (the Chrome menu, then Bookmarks and lists, then Show bookmarks bar; Chrome's own help page "Create, find and edit bookmarks in Chrome" documents the path). Bookmark any page with the star to the right of the address bar, then open the Bookmark Manager, choose More, then Edit on that bookmark, and paste the one-liner into the URL field. Give it a short name; that name is what you click.

Firefox. Right-click the bookmarks toolbar, choose Add Bookmark, and paste the one-liner into the URL field with a name of your choice. If the toolbar is hidden, the View menu's Toolbars submenu shows it. Firefox also lets you edit an existing bookmark's URL from Manage Bookmarks. We could not load Mozilla's support page for this during this session, so check the current menu names in your version.

Safari (Mac). Apple's guide "Bookmark websites that you want to revisit in Safari on Mac" describes adding a bookmark from the Share button (Add Bookmark) and editing one by Control-clicking it and choosing Edit Address. Paste the one-liner as the address. The Favorites bar is the convenient place for it.

Mobile browsers. Bookmarklets work in Safari on iOS and in Chrome on Android with the same trick: bookmark a page, then edit the bookmark's URL to the javascript: code. On Chrome for Android you run it by typing the bookmark's name in the address bar and tapping it, not from a bookmarks bar.

Three habits that keep bookmarklets working. Wrap the code in (() => { ... })(); so your variables do not leak into the page and the bookmark's return value is undefined (a bare expression that returns a string would replace the page with that string). Test on both a tweet page (/handle/status/<id>) and a profile page (/handle), because the two have different URLs and markup. And re-read the one-liner before pasting: anything you did not write yourself, including from this page, deserves a look.

X shows post times rounded to the minute, and relative ("3h") in timelines. The ID carries the millisecond. A tweet ID is a Snowflake, the ID scheme Twitter published in 2010 and whose archived reference implementation (github.com/twitter-archive/snowflake, branch snowflake-2010) describes as "time - 41 bits (millisecond precision w/ a custom epoch gives us 69 years) - configured machine id - 10 bits - gives us up to 1024 machines - sequence number - 12 bits", with the custom epoch 1288834974657. Shift the ID right by 22 bits, add the epoch, and you have the Unix time in milliseconds.

The bookmarklet reads the ID from location.pathname (a tweet URL is /<handle>/status/<id>), does the shift with BigInt, and shows the result in UTC, in your local time, and as raw milliseconds. No request leaves the browser. It works on any /status/ page, including quoted or embedded tweets you open directly.

What we verified. The regex, the BigInt arithmetic and the date formatting were run under Node on a real ID from the study: 2111180963661435219 decodes to a UTC time with a .239 millisecond part, and the API's createdAt for that post is the same second. Across the full sample of 960 posts, the ID-derived time matched createdAt to the second for every one (see the study below). The alert text and the DOM-free design mean there is nothing on this one to "verify in your browser" beyond the bookmark itself.

For many IDs at once, paste them into our Twitter timestamp tool instead; it does the same math for a whole list and accepts full URLs.

Pasting a tweet into notes, an issue tracker or a document usually means copying the URL, then the handle, then the text. This bookmarklet builds [@handle](https://x.com/handle/status/id) - text and puts it on the clipboard. The URL is rebuilt from the path, so tracking parameters such as ?s=20 are dropped and the host is always x.com.

The DOM part, verify in your browser. The tweet's text is read from the first element matching article[data-testid="tweet"] [data-testid="tweetText"], which is x.com's current markup for the main post on a status page; those data-testid attributes are a convention of the X web app, not a documented contract, and may change without notice. If the selector finds nothing (for example on a post that is only media), the bookmarklet still copies the link and handle. The URL and markdown assembly were run under Node; the selector was not exercised in a browser during this build.

Clipboard permission. navigator.clipboard.writeText needs a user gesture; clicking a bookmark normally counts, but if your browser rejects the write the bookmarklet falls back to a prompt() showing the text so you can copy it by hand. For plain text instead of markdown, change the md line to '@' + m[1] + ': ' + text + ' ' + url.

Both of these read the handle from the first path segment, which is the profile's handle on /handle, /handle/with_replies, /handle/media and on a tweet page /handle/status/<id>. A short list of reserved first segments (home, explore, search, notifications, messages, i, settings, compose) is rejected so the bookmarklet does not treat the home timeline as a user called "home". The list is ours, not X's; if you hit a reserved path we missed, add it.

Bookmarklet 3 copies the handle to the clipboard and opens our Twitter ID finder in a new tab. The tool takes the username in its form rather than from the URL, so paste it and press Enter; the numeric ID is what you need for API calls, for follower exports, and for telling two accounts with the same display name apart. The bookmarklet cannot fill the form for you, and it cannot call the lookup from x.com itself, because of the connect-src rule above; opening the tool page is a navigation, which is allowed.

Bookmarklet 4 opens https://x.com/search?q=from:<handle>&f=live in a new tab: the account's own posts, newest first, including replies, which is the fastest way to see what an account has said recently without scrolling its pinned post and reposts. Add -filter:replies inside the query if you want original posts only, or filter:links for posts with links; our advanced search guide lists the operators. The URL construction was run under Node (from:NASA becomes from%3ANASA, which x.com accepts).

Bookmarklet 5 combines the Snowflake math with search. It decodes the open tweet's ID to a date, then opens from:<handle> since:<day> until:<next day> as a live search, so you see the post in the context of everything the same account said that day: the thread it belongs to, the follow-ups, the corrections. The day is computed in UTC; if the post was made near midnight, the neighboring day is one click away in the search box. The URL that the code builds was checked under Node: for the @NASA post above it is from:NASA since:<day> until:<day+1> with both days as YYYY-MM-DD, which is the form X's since: and until: operators take.

Bookmarklet 6 is a toggle. The first click injects a <style> element that hides the right-hand sidebar column and the top banner and lets the main column use the space; the second click removes it. It changes nothing in your account and nothing persists after reload, which is the point: a reading mode for a long thread, gone when you want the trends back. The selectors ([data-testid="sidebarColumn"], header[role="banner"], main[role="main"], [data-testid="primaryColumn"]) are x.com markup conventions. Verify in your browser; if the sidebar is still visible after a click, open the inspector, find its container's data-testid, and edit the one line. Injecting a style element is permitted by x.com's style-src 'unsafe-inline', so CSP is not the reason if it fails.

A note on scope: none of the six bookmarklets logs in, posts, likes or follows. They read the page you are on and open pages you could open by hand. If what you want is to act on an account programmatically (post, delete, follow), that is a different tool with different consequences, which we cover in the FAQ.

Bookmarklet 1 claims that 22 bits of shifting and one addition give you a post's creation time. To check, we fetched the most recent posts of six organization accounts through /twitter/user/last_tweets (replies excluded by default, newest first, up to 10 pages of 20): 200 each from @NASA, @github, @googlechrome and @mozilla, 120 from @esa, and all 40 that @firefox has posted. 49 requests, 960 posts, about $0.14 in API reads. For every post we decoded the ID exactly as the bookmarklet does and compared it with createdAt, which the API returns at second precision in the form %a %b %d %H:%M:%S %z %Y (weekday, month, day, time, offset, year).

They agree, every time. For 960 of 960 posts the ID-derived time, truncated to the second, equals createdAt. The difference between the millisecond value from the ID and createdAt was never negative and never reached 1,000 ms: minimum 2 ms, median 475 ms, mean 493 ms, maximum 998 ms. That is the signature of a field that was simply rounded down: the ID keeps the millisecond, createdAt drops it. The histogram below shows the leftover spread almost flat across the ten 100 ms bins (88 to 106 posts per bin, against 96 expected if uniform), which is what you get when the sub-second part is effectively random.

So the bookmarklet is not just as good as the API's timestamp; it is more precise. If you need to order two posts made within the same second, the ID decides and createdAt cannot. Reposts are a case to know about: 28.8% of the sample were reposts (@NASA 45.0%, @esa 41.7%), and for those the ID and createdAt both describe the repost itself, not the original post; the original's time is in retweeted_tweet.id, decoded the same way.

"Leftover" is the ID-derived millisecond time minus createdAt in milliseconds. Days spanned is oldest to newest post in each sample; the two-year spans belong to accounts that post rarely.

The low 22 bits of a Snowflake are the machine and sequence fields. The archived Twitter implementation splits the 10 machine bits into a 5-bit datacenter ID and a 5-bit worker ID, and the 12-bit sequence counts IDs minted in the same millisecond on the same worker. Decoding them is one line each ((id >> 17) & 31, (id >> 12) & 31, id & 4095), and it is a harmless curiosity: nothing about a user is in there. We decoded them for the 960 posts to see what the field values look like in 2026.

The sequence field is the surprise if you expect it to start at 0 for every millisecond: only 1 of 960 IDs had a zero sequence, and the median was 258. That is consistent with a generator that does not reset the counter per millisecond (the archived code starts from a random or rolling value depending on the version), and it is a reminder not to read more into those bits than "which generator, roughly in what order". The timestamp bits are the ones with a documented meaning; the rest are an implementation detail that has evidently changed since 2010.

Where bookmarklets stop. A bookmarklet sees one page. The moment the question is "when were these 500 tweets posted", "what is the ID for each of these 200 handles", or "give me this account's posts with timestamps as a CSV", you want the data as JSON, and x.com's connect-src means the bookmarklet cannot fetch it for you. The Python at the end of this page is the same comparison we ran, against the twitterapi.io endpoints: /twitter/tweets with tweet_ids returns id and createdAt for a list of IDs, and /twitter/user/last_tweets pages through an account's timeline with has_next_page and next_cursor. No X account or developer app is needed for reads; the key goes in an X-API-Key header.

Cost, with the rate cards named. Tweet endpoints on twitterapi.io bill 15 credits per tweet returned, $0.15 per 1,000 tweets ($1 = 100,000 credits), with a 15-credit minimum per request; a full 20-tweet page is $0.003, and this study's 960 posts cost about $0.14. The official X API pay-per-usage rate card (docs.x.com/x-api/getting-started/pricing) lists $0.005 per post read, $5 per 1,000, about 33x more, capped at 3 million post reads a month before Enterprise. Profiles are 18 credits each on twitterapi.io ($0.18 per 1,000) against $0.010 per user read on X's card. New twitterapi.io accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days), which covers roughly seven studies of this size; purchased credits never expire. Rate limits are 0.2 requests per second before the first payment and 20 once paid; see the pricing page for plans.

Question: does the Snowflake arithmetic a bookmarklet can run in the browser, (id >> 22) + 1288834974657 milliseconds, reproduce the creation time the API reports in createdAt; how large is the difference; and what do the remaining 22 bits of the ID contain in practice.

Accounts and endpoint: six public organization accounts, @NASA, @esa, @firefox, @github, @googlechrome and @mozilla, through /twitter/user/last_tweets with the default includeReplies (replies excluded), newest first, up to 10 pages of 20 per account. @esa was limited to 6 pages to stay within the request budget and @firefox has only 40 posts. 49 requests, 960 posts, collected in 2026 through a rate-limited, read-only client.

Method: for each post, the ID string was parsed as a 64-bit integer; timestamp = (id >> 22) + 1288834974657 ms, datacenter = (id >> 17) & 31, worker = (id >> 12) & 31, sequence = id & 4095. createdAt (format %a %b %d %H:%M:%S %z %Y) was parsed to epoch seconds. We report the delta in milliseconds, the share matching at second precision, the share with the same UTC date, the histogram in 100 ms bins, and the distribution of the three low fields. Reposts and quotes were counted from the presence of retweeted_tweet and quoted_tweet.

What the sample cannot show: the timeline endpoint returns createdAt at second precision, so we can confirm agreement to the second and characterize the sub-second leftover, but not verify the millisecond itself against an independent clock. Six organization accounts over the last two years say nothing about IDs from 2010 to 2015, when the generator's machine and sequence fields may have behaved differently; the timestamp field's meaning has not changed. The DOM selectors used by bookmarklets 2 and 6 were not exercised here; this study is about the arithmetic.

Aggregates only. The accounts named are organizations; no individual's posts were analyzed and no post text was used. The analysis script, results and the gzip-compressed raw pages for these organization accounts are kept with the study.