Tweet.md Browser Redirect 2026: Replace x.com Links

On July 13, 2026, tweet.md hit Show HN's front page with a single, sharp idea: replace every x.com link on the open web with a Markdown rendering of that post. No login wall. No algorithmic feed. No tracking pixels. Just the post text, the author handle, the timestamp, and any media links — served as plain text you can copy, paste, or read with eyes that are not bleeding from a fourth feed refresh.

The mechanism is a browser-level redirect. You install an extension, paste a redirect pattern, and from that moment forward every link that points at x.com/<user>/status/<id> is rewritten to tweet.md/<user>/status/<id>. The destination is a static Markdown rendering of the post. tweet.md handles the fetch server-side, so your browser never loads the X web app, never runs X's JavaScript, and never sees a single X cookie.

This is not the same product as ThreadGrab, and the two are not in competition. tweet.md is a read-path tool. ThreadGrab is an archive-path tool. This guide walks through tweet.md's redirect pattern, shows you the 3-step setup, and explains when to use each tool — and when to run both side by side.

H2-1: What tweet.md's Browser Redirect Does

tweet.md is a single-purpose service: given any X post URL, return a Markdown rendering of that post. The URL pattern is https://tweet.md/<username>/status/<post-id> and the response is a static HTML page that contains the post text, author handle, timestamp, media links, and any quoted tweet rendered as nested Markdown.

The browser redirect is what makes this useful at scale. Without a redirect, you would have to manually copy every X link, replace x.com with tweet.md, and paste the result. With the Redirector extension (or a Tampermonkey userscript), the rewrite happens transparently: any link you click — in email, in a Slack message, in a Reddit thread, in a Google Doc — is intercepted and sent to tweet.md before your browser loads X.

The redirect is stateless. tweet.md fetches the post server-side using its own X API access, renders Markdown, and serves it. Your browser never reaches x.com, never executes X's JavaScript bundle, and never sends a referrer header back to X. From a privacy standpoint, this is a clean separation: your reading is decoupled from X's tracking infrastructure.

H2-2: 3-Step Setup (Redirector Extension)

Setting up the redirect takes about 60 seconds. The example below uses the Redirector extension, which is available for both Firefox and Chrome with identical syntax.

Step 1: Install Redirector

Install the Redirector extension from your browser's addon store. Firefox users get it from addons.mozilla.org; Chrome users from the Chrome Web Store. Both versions are open source, weigh under 50KB, and request no permissions beyond reading URLs.

Step 2: Create the redirect rule

Open the Redirector options page and click Create new redirect. Paste the following pattern:

Description:  x.com to tweet.md
Example URL:  https://x.com/threadgrab/status/1234567890
Include pattern:  ^https://(x\.com|twitter\.com)/([^/]+)/status/(\d+).*
Redirect to:    https://tweet.md/$2/status/$3
Pattern type:   Regular Expression

The regex matches both x.com and the legacy twitter.com domain, captures the username and post id, and rewrites the URL to tweet.md's pattern. Save the rule. From this moment forward, every X link that matches is rewritten.

Step 3: Test and refine

Click any X link — in a search result, in an email, anywhere. Your browser should load tweet.md instead of x.com. If you see the Markdown preview, the setup is correct. If you land on X as before, double-check the regex against the redirector's test pattern field.

For users who prefer userscripts, the Tampermonkey equivalent is roughly 15 lines of JavaScript with the same regex match and window.location.replace() call. Both approaches are equally valid; pick the one your browser already supports.

H2-3: What tweet.md Renders (and What It Drops)

tweet.md's output is intentionally minimal. The Markdown rendering includes:

• Post text — full text including line breaks, hashtags, and @mentions rendered as plain text.
• Author handle — the @username prefixed to the post, formatted as a link back to the user's tweet.md profile.
• Timestamp — the post creation time in ISO 8601, rendered as a small caption.
• Media links — image URLs as Markdown image syntax; video URLs as plain links (no inline playback).
• Quote tweets — nested Markdown blocks with the quoted author's handle and full text.
• Thread continuation — if the post is part of a thread, the in_reply_to chain is followed and rendered as a single Markdown document.

What tweet.md does not include is just as important. There are no like counts, no retweet counts, no reply threads, no follower counts, no "related posts" sidebar, no promoted content, no login prompts. The page is the post and nothing but the post.

This is exactly what you want for reading. It is also exactly what you do not want for archiving. tweet.md does not download media to your disk, does not preserve EXIF metadata, does not track post corrections over time, and does not give you a file you can store in your own folder. It is a rendering service, not a backup tool.

H2-4: How tweet.md Differs from ThreadGrab

The table below summarizes where the two tools overlap and where they diverge. The short version: tweet.md is for reading, ThreadGrab is for keeping.

For pure reading — checking a link someone sent you, scanning a thread without losing 20 minutes to "For You" — tweet.md is the faster tool. For saving content you want to keep — a thread you'll reference next week, a research thread you'll cite in a post, a public statement you want to preserve as evidence — ThreadGrab is the right tool.

H2-5: Pairing tweet.md with ThreadGrab

The recommended setup for creators who consume a lot of X content is to run both. Use tweet.md as your default read path — every X link in your email, your chat apps, your search results becomes a Markdown preview automatically. Use ThreadGrab when you encounter a thread you want to keep: click the ThreadGrab icon in your browser (or paste the URL into the web app), and the full thread is archived as Markdown files on your disk with media downloaded.

This division of labor maps cleanly to how creators actually use social content. Most X links are throwaway: someone shares a hot take, you read it once, you move on. Those links should not clutter your archive. But every few days you encounter a thread that is worth keeping — a how-to, a research summary, a public statement. Those threads go into ThreadGrab, get indexed by your local search, and become part of your long-term knowledge base.

The two tools do not interfere with each other. tweet.md's redirect runs at the browser level and only triggers on X links. ThreadGrab runs as a web app or a one-click browser action. You can keep both installed indefinitely without conflicts.

H2-6: When to Use Which Tool (Decision Matrix)

Use this quick decision tree when you encounter an X link:

1. Will I read this once and move on? → Let tweet.md handle it. The redirect happens automatically.
2. Do I need to download media (images, video, screenshots)? → ThreadGrab. tweet.md only links to media.
3. Will I cite or quote this thread in future work? → ThreadGrab. Archived Markdown is searchable and citable; tweet.md renderings are ephemeral.
4. Does this post matter as evidence of a public statement? → ThreadGrab with version tracking. You want the historical record, including any future corrections.
5. Am I researching a topic and need 50+ threads on the same subject? → ThreadGrab bulk export. tweet.md is for individual links, not bulk.
6. Do I just want to read a thread without doomscrolling? → tweet.md. This is exactly what it was built for.

The two tools cover complementary use cases. Trying to force one to do the other's job leads to frustration: tweet.md is not an archive, ThreadGrab is not a read-optimized viewer.

H2-7: Privacy and Data Flow

Both tools improve on X's default tracking, but in different ways. tweet.md's redirect means your browser never executes X's JavaScript, never sets X cookies, and never sends a referrer to X. tweet.md itself sees your IP and the URLs you request, but does not log in to X on your behalf and does not require an X account.

ThreadGrab's privacy model is different: it fetches posts using its own X API access, processes them server-side, and returns Markdown files to you. Your X account is never used, and your reading history is not exposed to X. The output files live on your disk or in your chosen storage backend (GitHub, Notion, S3), so you control the data.

If your threat model is "I don't want X to track my reading," both tools solve the problem at the browser level. If your threat model is "I want my own copy of every important thread I encounter," ThreadGrab is the right choice. The two are not mutually exclusive.

H2-8: Limitations of the tweet.md Redirect

The redirect is not magic, and it has real limits:

• Posts deleted or made private will fail to render. tweet.md cannot fetch content that no longer exists on X.
• Long threads (20+ replies) can take a few seconds to render because tweet.md follows the reply chain server-side.
• Premium X content (X Premium subscriber-only posts) may not be accessible to tweet.md's API tier.
• Polls render as plain text only — you see the question and options, but not the live vote counts.
• Spaces (live audio) are out of scope. Spaces are ephemeral audio rooms and tweet.md does not transcribe or archive them.

For most use cases, these limits do not matter. If you regularly work with long threads, deleted content, or polls, ThreadGrab's archival approach (with re-fetch on demand) handles those cases more gracefully.

FAQ