Nitter Is Archived: Which Nitter Alternatives Still Work in 2026?
If you are here, a Nitter link stopped working: a bookmark, an RSS feed, a browser redirect extension, or a script. Nitter was the open-source, JavaScript-free, account-free way to read X, and for years "just use a different instance" was the fix. In 2026 that advice has a short shelf life, because the project is archived and the instances that remain are fighting both X and the scrapers that abuse them.
This page is about Nitter as a whole: what happened to the project, which of the listed instances actually respond today (we checked rather than copying a list), and what replaces each of the things Nitter did. If you came specifically from xcancel.com, the most-linked instance, we have a separate page on xcancel's suspension and its direct replacements; this one is the wider map.
Our method for the instance check is simple and repeatable: three plain HTTP requests per URL with a desktop browser user agent, no cookies, no JavaScript, to the @NASA profile page and to its RSS feed on each instance. That is what feed readers, link previewers, and scripts see. A full browser can sometimes pass a bot challenge that a script cannot, and we say so where it matters.
What happened to Nitter: the timeline
Nitter launched on 19 June 2019 as an alternative front end for Twitter: no JavaScript, no ads, no tracking, an RSS feed for every profile, and no account needed. It worked by using Twitter's unofficial guest-token API, the same one the official app used for logged-out visitors.
January 2024: X removed guest accounts. The developer declared the project dead, and the flagship nitter.net went offline as instances failed through February. 6 February 2025: development resumed, with a catch that defines everything since: an instance now needs real X account sessions, supplied by its operator, to fetch anything. The Nitter wiki says it plainly: "Nitter requires real accounts to authenticate API requests."
24 August 2026: the project's README records that X Corp. sent cease-and-desist letters "demanding a permanent takedown of Nitter instances and the project's repository". The repository was archived the next day. 6 September 2026: the README was updated to say that "following legal advice, the Nitter project will continue", and xcancel came back online for a few days. 11 September 2026: the repository was archived again, read-only, and xcancel went dark "until further notice". That is where things stand as we write, in 2026.
The practical reading: the code still exists and still runs, operators can still host it, but there is no development, no official instance, and an explicit legal threat hanging over anyone who runs a public one. Nitter is not dead the way it was in 2024; it is unsupported and under pressure, which for a user means instances will keep appearing and disappearing without notice.
We checked 12 Nitter instances: here is what each one returns
Lists of Nitter instances are everywhere; what they rarely tell you is whether an instance will answer a feed reader or a script today. So we asked. The hosts below are every instance on the community status tracker at status.d420.de (seven listed, six marked healthy when we looked) plus the regular instances on the project wiki, plus nitter.net and xcancel for completeness. Three requests per URL in 2026; the median response time is for the three.
Three findings matter more than any single row. Feeds outlive pages. Three instances answered the RSS URL with a full 20-post feed every time while refusing or challenging the profile page; RSS is clearly the use case operators are still protecting. A 200 is not a working page. Four instances returned HTTP 200 and no posts, because the 200 was a bot-check or queue page (two of them run Anubis, a proof-of-work challenge that needs JavaScript). A status tracker that counts 200s will call these healthy; a feed reader will not. The lists are stale. Of the seven regular instances on the project wiki, only one returned any content to us, and two no longer exist at their listed address.
A caveat in the other direction: our network is one vantage point. nitter.poast.org and nitter.net failed to connect from here, which may be our route rather than their server. Everything marked 403, 418, 451, or a bot-check page was a real response from the instance.
Why Nitter instances keep breaking
Understanding the failure helps you choose a replacement that does not fail the same way. Four forces act on every public instance, and in 2026 all four are pushing at once.
1. Every instance runs on borrowed X accounts. Since the 2025 revival, an instance fetches data by replaying session tokens from real X accounts its operator created. The wiki page on creating session tokens describes the process; the README warns that running a large public instance "is not feasible with a small amount of accounts". When X locks those accounts, the instance returns errors or empty timelines until the operator makes more.
2. Scrapers treat free instances as a free API. The README notes that RSS feeds are "often disabled due to abuse", and the status tracker's own page asks visitors not to use the instances for scraping and to host Nitter themselves. The bot checks and access queues we hit are the operators' answer: they protect the account pool at the cost of breaking every feed reader and script.
3. X's rate limits are per account. A busy instance spreads thousands of readers over a handful of accounts, so it hits limits that a single person never would. Timelines go blank at peak hours even when nothing is "down".
4. Legal pressure. The cease-and-desist letters of August 2026 and xcancel's legal suspension mean an instance can be healthy on Monday and gone on Tuesday with no technical cause. This is the new factor since 2025 and the reason "find another instance" is no longer a plan.
The common thread: any service that fetches X data on your behalf using X accounts it does not own is one lock, one abuse wave, or one letter away from going dark. A replacement that does not share that dependency is the only one you can rely on.
Nitter alternatives by what you actually used it for
Nitter bundled five jobs into one URL. Split them apart and the right replacement for each becomes obvious. "Works now" reflects our 2026 check and the project's current state; we mark what we could not confirm.
Two rows deserve a note. Fixer services (fxtwitter and similar) are not Nitter alternatives in the reading sense; they rewrite a post link so Discord, Telegram, or Slack shows a proper preview, and they are the right answer to the "embed" part of the Nitter job. And self-hosting is the honest option for RSS die-hards: the archived repository still builds, the wiki still explains session tokens, and a private instance serving one person is well under any rate limit. It just is not account-free, which was half the point of Nitter.
Self-hosting Nitter in 2026: what it takes now
Because the repository is archived rather than deleted, you can still clone and run it, and a private instance avoids the abuse problem entirely. Here is what the project's own documentation says you need, as of its last update.
One or more X accounts you are willing to risk. The wiki page on creating session tokens walks through logging in and exporting the session into the sessions.jsonl file the instance reads. Accounts used this way can be locked; use ones you can afford to lose.
A small server with Redis, and ideally a reverse proxy such as Nginx in front, as the README recommends for security and performance.
No expectation of updates. With the repository read-only, any change on X's side that breaks fetching will stay broken unless a fork fixes it. Watch the community forks and the status tracker's discussions for patches.
Keep it private. Do not list it, do not share the URL, and you will never need a bot check. The entire failure mode of public instances comes from strangers' traffic against your accounts' rate limits.
Replace the Nitter feed with an API: a merged timeline for a list of accounts
The thing Nitter did best, a plain chronological timeline of the accounts you care about, is two read-only calls per account on twitterapi.io: GET /twitter/user/info for the profile card and GET /twitter/user/last_tweets for the newest posts (up to 20 per page, with a cursor for more). No X account, no session tokens, no instance to go down; an API key from the dashboard is the only credential.
The script below reads a list of handles, merges their latest posts into one timeline sorted newest first, and writes it as a single static HTML page you can open in any browser, drop on a static host, or point a reader at. It is the Nitter list view without Nitter. Set TWITTERAPI_IO_KEY first. If what you want is RSS specifically, the xcancel page linked below has a sibling script that writes one RSS file per account; the two are drop-in companions.
Two notes from the endpoint docs. The post list can arrive at the top level or under data depending on the endpoint version, so the helper checks both. And createdAt uses X's classic format (Tue Oct 07 09:00:00 +0000 2026), which the script parses to sort across accounts.
"""Nitter-style merged timeline for a list of accounts, written as one static HTML page.
Run it from cron (e.g. every 10 minutes) and open timeline.html in any browser.
Needs TWITTERAPI_IO_KEY in the environment.
"""
import html
import os
from datetime import datetime
import requests
HEADERS = {"X-API-Key": os.environ["TWITTERAPI_IO_KEY"]} # from twitterapi.io/dashboard
ACCOUNTS = ["NASA", "nasawebb", "ESA"] # handles you used to read on Nitter
X_DATE = "%a %b %d %H:%M:%S %z %Y"
OUT = "timeline.html"
def latest_posts(username):
r = requests.get(
"https://api.twitterapi.io/twitter/user/last_tweets",
params={"userName": username, "includeReplies": "false"},
headers=HEADERS,
timeout=30,
)
r.raise_for_status()
body = r.json()
posts = body.get("tweets") if isinstance(body.get("tweets"), list) else (body.get("data") or {}).get("tweets", [])
for p in posts:
p["_user"] = username
try:
p["_ts"] = datetime.strptime(p.get("createdAt", ""), X_DATE)
except ValueError:
p["_ts"] = datetime.min
return posts
def render(posts):
rows = []
for p in posts:
text = html.escape(p.get("text") or "")
rows.append(
f"<article><header><b>@{html.escape(p['_user'])}</b> "
f"<time>{p['_ts'].strftime('%Y-%m-%d %H:%M UTC') if p['_ts'] != datetime.min else ''}</time></header>"
f"<p>{text}</p>"
f"<footer>{p.get('likeCount', 0)} likes, {p.get('retweetCount', 0)} reposts "
f"<a href=\"{html.escape(p.get('url') or '')}\">open on X</a></footer></article>"
)
return (
"<!doctype html><meta charset=utf-8><title>Timeline</title>"
"<style>body{max-width:640px;margin:2rem auto;font:16px/1.5 system-ui;color:#eee;background:#111}"
"article{border-bottom:1px solid #333;padding:1rem 0}time,footer{color:#888;font-size:.9em}a{color:#8ab4f8}</style>"
+ "".join(rows)
)
if __name__ == "__main__":
merged = []
for handle in ACCOUNTS:
merged.extend(latest_posts(handle))
merged.sort(key=lambda p: p["_ts"], reverse=True)
with open(OUT, "w", encoding="utf-8") as f:
f.write(render(merged))
print(f"wrote {len(merged)} posts from {len(ACCOUNTS)} accounts to {OUT}")
What the API route costs compared with the official X API
Nitter was free until it was not. If you move the reading to an API, here is the bill for the Nitter-shaped unit of work, one profile plus its 20 latest posts, using each provider's published per-unit prices as checked in 2026.
The ratio is roughly 34 times ($0.11 / $0.0032). twitterapi.io also has a $0.00015 minimum per call, which matters only when a call returns almost nothing. The honest comparison with Nitter itself: a public instance is free, a self-hosted one costs a small server and your time, and the API costs real money but is the only one of the three that cannot be suspended, rate-limited by X, or taken down by a letter. Choose by how much you would lose if the feed stopped tomorrow.
"""Check which Nitter instances answer a feed reader right now, before you point anything at them.
Sends N plain requests to the profile and RSS URL of each host and prints what came back.
No API key needed; this is the method behind the table on this page.
"""
import statistics
import sys
import time
import requests
HOSTS = ["nitter.kareem.one", "nitter.meowing.monster", "shitter.thepixora.com", "nitter.netbub.com"]
HANDLE = "NASA"
REQUESTS_PER_URL = 3
UA = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0 Safari/537.36"
def probe(url):
t0 = time.time()
try:
r = requests.get(url, headers={"User-Agent": UA}, timeout=20, allow_redirects=True)
body = r.text
posts = body.count("<item>") if url.endswith("/rss") else body.count("timeline-item")
bot_page = any(s in body for s in ("not a bot", "Access Queue", "Just a moment", "Checking you"))
return r.status_code, time.time() - t0, posts, bot_page
except requests.RequestException:
return "ERR", time.time() - t0, 0, False
if __name__ == "__main__":
hosts = sys.argv[1:] or HOSTS
for host in hosts:
for path in (f"/{HANDLE}", f"/{HANDLE}/rss"):
results = [probe(f"https://{host}{path}") for _ in range(REQUESTS_PER_URL)]
codes = [str(c) for c, _, _, _ in results]
median = statistics.median(dt for _, dt, _, _ in results)
posts = [p for _, _, p, _ in results]
bot = any(b for _, _, _, b in results)
verdict = "posts delivered" if max(posts) > 0 else ("bot check / queue page" if bot else "no content")
print(f"{host + path:48} {'/'.join(codes):14} {median:5.2f}s {verdict}")
Questions readers ask
Is Nitter dead in 2026?
The project is archived, not deleted. X Corp. sent cease-and-desist letters on 24 August 2026; the repository was archived, briefly revived in early September when the project said it would continue, and archived again on 11 September 2026. Instances still run on their operators' X account sessions, but there is no development and no official instance. Treat it as unsupported and unpredictable rather than dead.
Which Nitter instances are still working?
It changes week to week. When we checked in 2026, nitter.kareem.one, nitter.meowing.monster and shitter.thepixora.com returned a full RSS feed on every request, while their profile pages sat behind bot checks; nitter.jaydenha.uk, nitter.xitter.cc, nitter.tiekoetter.com and nitter.netbub.com returned only bot-check or queue pages to a script; nitter.net, nitter.click and nitter.poast.org did not respond; nitter.privacyredirect.com is gone; xcancel.com is suspended. Check the community tracker at status.d420.de right before you rely on one.
Why do Nitter instances show a bot check or an access queue?
Because the instance is protecting its small pool of X account sessions from scrapers. Since 2025 every instance fetches data with real X accounts, which X rate-limits and locks, so operators put proof-of-work challenges such as Anubis or a waiting queue in front of pages. A real browser usually passes; feed readers and scripts do not.
What is the best Nitter alternative for RSS?
Three options: a public instance whose RSS still works (three did in our check, but expect churn), a self-hosted Nitter using your own X account sessions, or feeds generated from a read-only API. The API route is the only one that does not depend on X accounts that can be locked; the xcancel page linked on this page has a script that writes one RSS file per account.
Can I still view Twitter without an account?
Partly. Logged-out x.com loads individual posts and profile pages but sends search to the login screen. A healthy Nitter instance in a browser still works for profiles and search while it lasts. For search or bulk reading without any X account, a read-only API that only needs an API key is the dependable route.
Is self-hosting Nitter still possible?
Yes. The archived repository still builds, and the wiki explains how to create the session tokens the instance needs. You must supply your own X accounts, which can be locked, and you should keep the instance private so strangers' traffic does not burn through your accounts' rate limits. There will be no upstream fixes if X changes something.
Is using Nitter legal?
Reading public posts through a Nitter instance has not been treated as unlawful for users; the legal pressure in 2026 is aimed at instance operators and the project, through cease-and-desist letters alleging scraping. Running a public instance now carries that risk; using one does not, though it may disappear under you.
Continue
- Nitter on GitHub: archived repository, README with the cease-and-desist and continuation notices
- Nitter wiki: community instance list (last updated before the archive)
- Nitter wiki: creating session tokens, why instances need real X accounts
- nitter-status: third-party uptime tracker for public instances
- Wikipedia: Nitter, dated history of the 2024 shutdown, 2025 revival, and 2026 archive
- X API pay-per-usage pricing (docs.x.com), the official and more expensive route
- twitterapi.io docs: Get User Last Tweets endpoint
- Twitter (X) API overview: the hub for reading X data
- xcancel alternatives: the suspended instance and its direct replacements
- Read X without an account through a read-only API
- Build a Twitter (X) viewer on the API
- fxtwitter: fixing X link previews in Discord and Telegram
- Scrape Twitter (X) without the official API
- twitterapi.io pay-per-call pricing
Stop reading. Start building.
Starter credits cover real testing on real data. Google sign-in, no card, no application queue.
Get an API key