# What t= and s= mean in an X (Twitter) share URL - Canonical: https://linkclean.app/learn/x-twitter-share-url-explained/ - Updated: 2026-07-20 - Author: Ken Tominaga (https://ken0nek.com) - Get the app: https://apps.apple.com/us/app/linkclean/id6758604043 > Every X share URL ends with `?t=&s=<2-digit-code>`. **`s` encodes the device + sharing method** (Android Copy Link, iPhone Copy Link, Twitter Web Email, etc. — 71 distinct codes have been catalogued from Twitter's own JavaScript). **`t` is a per-device session token** that lets X correlate multiple shares from the same source within a time window. Both are pure tracking; the tweet loads identically without them. LinkClean strips both, host-scoped to `x.com` / `twitter.com` so it doesn't touch `t=` on YouTube (where it's a timestamp). ## Anatomy of an X share URL Pick any tweet, tap Share → Copy Link, and you get something like: https://x.com/handle/status/1234567890123456789?t=AbCdEf-12345_xyz&s=46 The path — /handle/status/ — is the only part the server cares about. Open the URL with the path alone and you get the same tweet; the `?t=…&s=…` tail exists purely for X's attribution funnel. - `/handle/` — the account that posted the tweet (or any retweeter). - `/status/` — the unique tweet identifier; the only part X needs to render the page. - `?t=` — a per-device session token (more below). - `&s=<2-digit code>` — which device + sharing method generated this share URL (the focus of this article). ## The `s` parameter — device + sharing method `s` is a two-digit code (always 2 digits — `s=09`, `s=19`, `s=46`, etc.) that X uses to record exactly which client + which button generated the share URL. Each code is a unique combination of: - **Device type** — Android phone, iPhone, iPad, Twitter Web (desktop), Twitter Web (mobile), or a third-party Twitter client like Gryphon. - **Sharing method** — Copy Link, Email, SMS, WhatsApp, Telegram, Messenger, Facebook, Snapchat, Instagram, LinkedIn, Slack, Discord, Reddit, Line, Kakao, Viber, WeChat, Hangouts, Gmail, Twitter DM, and a few platform-specific options. - **71 distinct codes** have been catalogued in total, by analysing Twitter's own front-end JavaScript (see Unfurl, the social-media URL parser). ## Common `s` values you'll see in the wild These are the ones that show up most often when you copy a tweet URL. The mapping is reverse-engineered from Twitter's JS by community researchers, not officially documented — but it's stable across years of observation: *Common s-codes when copying a tweet URL* | Value | Device | Sharing method | | --- | --- | --- | | s=09 | iOS (older Twitter app) | Native share menu | | s=12 | iOS | iOS share sheet | | s=17 | Twitter Web (desktop) | Email share | | s=18 | Twitter Web (desktop) | Download / direct | | s=19 | Android | Copy Link button | | s=20 | Twitter Web (desktop) | Copy Link button (the most common in the wild) | | s=21 | Twitter Web (newer UI) | Copy Link button | | s=41 | Gryphon (3rd-party iOS client) | Copy Link | | s=46 | iPhone Twitter app | Copy Link button | ## What does `s=46` specifically mean? `s=46` means **the share URL was generated by tapping “Copy Link” in the Twitter (X) iPhone app**. If a friend forwards you a tweet and the URL ends in `?t=…&s=46`, they used the iPhone app's Copy Link button — not the share sheet, not the web, not Android. It's the iPhone-app counterpart to `s=20` (Twitter Web Copy Link) and `s=19` (Android Copy Link). Together with `t=`, X can tell that a particular tweet was copied from a particular iPhone session at a particular time, and whether subsequent shares of the same tweet came from the same source or different sources. The forensic-grade detail of this scheme is also why removing `s=` and `t=` before forwarding is the right default: they encode quite a bit more than the destination needs. ## The `t` parameter `t` is an opaque token that's not officially documented, but observation shows it's consistent per device for a time window — multiple shares from the same Twitter session tend to carry the same or related `t` values, while shares from different devices have different ones. That makes `t` useful to X as a join key: if two share URLs of the same tweet arrive at X's pixel with the same `t`, they almost certainly originate from the same device session — which lets X reason about virality (one tweet shared by a thousand different `t` values is genuinely spreading; one tweet shared a thousand times by a single `t` value looks like abuse). From your point of view, the privacy concern is that `t` ties any pageview through that URL back to your device session — even after the share has bounced through multiple recipients. ## What does X actually learn from these? Combined, `t` and `s` give X a fine-grained attribution signal every time someone clicks a share URL: - **Which device produced the share** — the `s` code identifies the device category and the surface (iPhone app, Android, web). - **Which sharing button was used** — `s` also encodes the button (Copy Link, Email, Snapchat, SMS, …). - **Approximate device fingerprint via session** — `t` correlates multiple shares from the same session, even across tweets. - **Funnel analytics** — how often a tweet gets shared, on which surfaces, and how often those shares convert to engagement back on X. - **Abuse signals** — repeated identical `t` across a tweet's share URLs suggests automation or coordinated sharing. ## How LinkClean removes `t=` and `s=` (without breaking YouTube) Naïvely stripping any `t=` parameter would break YouTube share links — YouTube's `t=42` is the start-at-N-seconds timestamp, not a tracker. LinkClean's catalog scopes the `t/s` cleaning rules to `x.com` and `twitter.com` only. On those hosts, `t` and `s` are stripped on every cleaning surface (share extension, widget, app, QR). On every other host they're left alone. Same goes for X's less-common share-tail parameters: `cn=` and `refsrc=` (X-specific) both ship default-on, host-scoped. The cleaned URL is `https://x.com/handle/status/` — the canonical permalink you'd get by typing the URL into the address bar yourself. If you want to see this transformation explicitly, paste an X share URL into the LinkClean app — the History view shows the original alongside the cleaned version, with `t`, `s`, and any extras called out as stripped. ## Frequently asked **If I keep `s=46`, what does X learn about me?** X learns that whoever clicked the URL is engaging with a link generated from a specific session on a specific iPhone. Joined with `t=`, X can tell if this is the same session that produced the share, or someone else (a forward recipient). **Are there 71 distinct s codes, really?** Yes — 71 codes have been catalogued across five device categories (Android, iOS, iPhone, iPad, plus desktop web and special clients). The full list was extracted from Twitter's own front-end JavaScript by community researchers (Unfurl, the open-source social-media URL parser, is the canonical reference). **Why does X bother encoding the sharing method?** Attribution and abuse detection. Knowing which surface produced each share lets X measure which sharing buttons drive engagement, A/B-test new buttons, detect automation patterns (mass shares from a single session), and credit shares back to source-app metrics. **Are `t` and `s` personal data?** Not by themselves — they don't carry your username or email. But X can join them to your account on their side via the cookie or app session that produced the share. Functionally, yes: they identify the share's source to X. **Will the tweet still load without `t=` and `s=`?** Yes. The path — `/handle/status/` — is all X needs. The tail is purely for X's attribution funnel. The cleaned URL renders the same tweet, same thread, same everything. **Does LinkClean strip these on every site?** No — they're host-scoped to `x.com` and `twitter.com` in the catalog. That's intentional: `t=` is a timestamp on YouTube, and `s=` is sometimes functional on other sites. LinkClean only strips them where they're known X trackers. **What about retweets and quote-tweets?** Same parameter scheme — the `s=` code identifies the share source the same way regardless of whether the underlying tweet is original, retweeted, or quoted. The `t=` token is bound to the device session, not the tweet. ## Related - [How to clean an X (Twitter) share link](https://linkclean.app/guides/clean-x-twitter-link/) - [What is fbclid?](https://linkclean.app/trackers/fbclid/) - [What's hidden in a share link?](https://linkclean.app/learn/whats-hidden-in-a-share-link/) - [Click IDs vs UTM tags — what's the difference?](https://linkclean.app/learn/click-ids-vs-utm-tags/) - [Do cleaned links still work?](https://linkclean.app/learn/do-cleaned-links-still-work/) --- LinkClean removes tracking parameters from links on-device — free to clean, one-time Pro. https://linkclean.app/ · Cite freely with attribution.