What remains distinctive about Nitter
Nitter's project README describes a lightweight X front end with no required JavaScript, backend-proxied requests, and instance-specific RSS. These features matter if you chose Nitter for a simpler browser or a feed reader, rather than merely to open a link.
The maintainer says X sent takedown demands on August 24, 2026; an October 10 note seeks funding and legal help. These are the project's dated statements. They make the operator and feature you use especially relevant when choosing a replacement.
A replacement reader can solve a single-post task without reproducing Nitter's proxy model, JavaScript behavior, or RSS. Start with the feature you want to keep.
What the same-account checks returned
The checks used @OpenAI and its May 13, 2024 announcement. PowerShell requested profile, post, and `/OpenAI/rss` paths on three Nitter instances, plus RSSHub's `/twitter/user/OpenAI` route. Fresh Chromium pages checked the post routes with JavaScript disabled.
CarryFeed was checked separately with JavaScript both disabled and enabled. With JavaScript enabled, submitting the same status link returned its text, @OpenAI, May 13 date, and original source link through a successful `/api/resolve` response.
These are observations from one network and one account, not an uptime ranking. No tested RSS path yielded a valid feed, so there are no feed-entry dates or later updates to report.
| Candidate | Reading result on October 15 | RSS result |
|---|---|---|
| XCancel | Profile and post returned HTTP 451 with the operator's service-suspended page. The no-JS browser showed the suspension. | /OpenAI/rss also returned 451 HTML. |
| Nitter Poast | PowerShell could not establish SSL; Chromium reported connection closed for the post. | The RSS request also failed to connect in this environment. |
| Nitter Tiekoetter | HTTP 200 contained an Anubis challenge; the no-JS browser received access denied. | /OpenAI/rss returned challenge HTML, not XML. |
| RSSHub public route | Checked as a feed route, not a browser reader. | The request ended at google.com/404 with an HTML 404 page; the redirect cause was not established. |
| CarryFeed | The JavaScript viewer retrieved the post. With JavaScript disabled, only the static form and guide loaded. | No account RSS subscription is currently offered. |
A healthy instance can still block your reader
The Nitter instance-health page listed Tiekoetter as healthy during the check. Its public post and RSS requests still reached bot protection from this environment. A health monitor and your browser or feed app can receive different responses.
For a no-JavaScript requirement, test the actual post page with scripts disabled. Here, Tiekoetter's challenge HTML explicitly required JavaScript; the browser received an Anubis denial instead of post text. A status of 200 would have hidden that failure if only the response code had been checked.
For RSS, inspect the response's content type and XML root before subscribing. The Tiekoetter response was `text/html`; parsing it produced no RSS or Atom feed. A successful web page, even one that works after a browser challenge, does not supply a feed reader with XML.
Choose a reader when the job is one public post
For a link you need to cite or summarize, start with the original status URL and use CarryFeed's Twitter Viewer. It worked for the OpenAI source in this check, with readable text and source details together. Use Copy full text or Export → Copy as Markdown after checking the result.
A Nitter link such as `https://instance.example/OpenAI/status/1790130708612088054` carries the same account and status path. Move that path to `https://x.com` when giving it to another reader; save the original X URL with your note.
Choose this route for occasional reading and exports when browser JavaScript is acceptable. It does not preserve the no-JS experience or replace an account feed.
If the post is not yet known, use account and date search first. A reader needs the right source; trying more mirrors will not identify which remembered announcement you meant.
Use LibRedirect to manage a working frontend
If you want X links to open through your chosen Nitter instance automatically, LibRedirect addresses that browser habit. Its current site lists Nitter for X; its documentation describes preferred instances, switching instances, and copying the original URL.
Choose an instance that you can actually read, then set it as preferred. LibRedirect makes that route convenient; it does not supply a new X data source or turn a suspended instance into a working service. The extension itself was not installed in these checks.
Nitter's backend-proxy design changes who handles the requests: you still send them to the instance operator. The checks here establish page and feed behavior, not an anonymity audit. Choose an operator you are comfortable using, or maintain your own instance when that control is the reason for migrating.
For RSS, choose who will maintain the data access
The four candidate paths did not produce a usable feed in this check. If RSS is essential, the practical choice is between finding an operator whose feed works for your account and maintaining a configured service. A public reader alone cannot take over that subscription.
For an existing Nitter setup, the official example configuration has `enableRSS` and `enableRSSUserTweets` switches for account feeds. The session guide says Nitter requires real X accounts and loads sessions from `sessions.jsonl`. GitHub marks the official repository archived and read-only since October 9, 2026. Self-hosting gives you control over the feed settings and access layer, while leaving you responsible for sessions, server operation, and upstream compatibility fixes.
For a dedicated feed service, RSSHub's user-timeline route is `/twitter/user/:id/:routeParams?`. Its current API selector chooses a configured third-party or web adapter, or a developer-API adapter. Without configuration it raises a Twitter API configuration error. This is a concrete self-hosted feed path, not evidence that the public RSSHub URL is ready for your subscription.
Neither self-hosted setup was deployed in this comparison. Before migrating your subscriptions, use your configured `/OpenAI/rss` or `/twitter/user/OpenAI` endpoint to obtain RSS or Atom entries, inspect their account and source links, then confirm a later new post arrives. Those steps establish the feed behavior that the public paths failed to provide here.
If maintaining a feed is more work than the task warrants, use an authenticated X List to follow a group of accounts inside X, or make occasional public lookups. This changes where you read future posts; it leaves your existing feed-reader workflow behind.
| Your priority | Path to choose | What you take on |
|---|---|---|
| A readable post and source export | CarryFeed or another reader verified for that post. | A JavaScript browser session; no continuing RSS delivery. |
| No-JavaScript Nitter browsing | A reachable Nitter instance, optionally routed through LibRedirect. | Verify the instance's access layer; the tested candidates did not deliver the no-JS post. |
| RSS with server control | Configured Nitter account RSS or RSSHub user timeline. | Data-access configuration, hosting, and actual feed refresh checks. |
| Follow accounts without maintaining a feed service | An X List in your authorized account. | Read inside X rather than your RSS app. |
Keep the source independent of the reader
Retain the original status URL, author, date, and text you used. Then a suspended mirror or changed browser extension does not erase the reference from your notes.
The dated observation record lists tested paths, results, and scope. For an AI discussion, the ChatGPT source-reading example follows the same OpenAI post through a completed summary and checks the claims against its historical date.