X Ended Seven Years of Nitter With a Letter and a 5pm Deadline. Check What of Yours Pointed At It.
On 24 August 2026, X Corp sent cease and desist letters demanding permanent takedown of Nitter instances and the project's repository. The letter gave until 5pm EST on 25 August. Nitter.net is offline, development has stopped, and the maintainer is seeking legal advice.
XCancel went with it, along with the other public instances. Seven years of a project that did one useful thing, ended by a PDF and a 29-hour deadline.
If you have ever pasted an xcancel.com link into a post, embedded one on a page, or pointed a script at a Nitter instance to read a feed without an API key, you have dead links and possibly a dead job. That is the practical part and I will get to it. The part that has stuck with me is a dependency lesson I had not thought through properly until this week.
What the letter actually says
The accusation is "unlawful use and circumvention of X's Application Programming Interface (API) and associated data." X says it has evidence that Nitter scraped X data and accessed X accounts and session tokens in violation of its rules.
The cited law is more interesting than the accusation. X's lawyers named the Texas Harmful Access by Computer Act and the Lanham Act, the federal trademark statute. Not the Computer Fraud and Abuse Act, which is the one people expect. A state computer-access statute plus a trademark claim is a combination that is cheaper to threaten with and harder for an individual maintainer to evaluate than a federal hacking charge would be.
And the demand covers the code repository, not only the running instances. That is the part I would underline. Taking down a service is a request about operations. Taking down the repository is a request about the existence of the software, and it is what makes this different from a rate limit.
This has happened before, and the difference is the point
In 2024, X killed nitter.net by technical means. New API restrictions broke it, the flagship instance went dark, and afterwards anyone hosting an instance had to attach a real X account to it.
Development picked back up anyway. Instances came back online. The project ran for another two years.
That is what a technical block looks like: it is an engineering problem, and engineering problems attract people who enjoy solving them. Legal process is not an engineering problem. There is no clever workaround for a maintainer who now has personal legal exposure and is being told to delete his repository. Zedeus is seeking legal advice and not commenting further, which is exactly the correct and exactly the fatal response.
I think this distinction is underrated when people assess platform risk. "Can they block us technically" and "can they make one unpaid person's life legally expensive" are very different questions, and the second one has a much worse answer for open source.
What broke on your side
Three categories, in rough order of how likely you are to have one.
Links in published content. If you wrote posts that cited X threads and used xcancel.com or a nitter instance to give readers a version they could read without logging in, those are 404s now. I did this. I checked my own archive and found links across several posts, all pointing at a domain that no longer resolves.
Embeds. Any page that iframed or server-side fetched a Nitter instance to render a post is now rendering an error or nothing at all. This is worse than a dead link because it may be failing silently in a layout you have not looked at in a year.
Automation. Cron jobs, RSS bridges, and monitoring scripts that read a feed through a Nitter instance because it did not require an API key. These fail quietly, and if you built any kind of "mentions" or "watch this account" feature on top, it has been returning nothing since Tuesday and probably did not tell you.
Go and grep for nitter and xcancel across your content directory and your scripts. It takes one command and it is the only way to find category three.
The dependency lesson
Here is what I got wrong in my own thinking, and I think it is common.
I treated a mirror as a safer version of the platform. Nitter did not need an API key, did not rate limit me the way the official API did, and did not require an account. It felt like the resilient choice, because it routed around the thing that could cut me off.
It was the opposite. A mirror of a platform you do not control is strictly more fragile than the platform itself, because it can be removed by the platform and by its own maintainer's legal exposure and by the ordinary attrition of unpaid volunteer work. Three independent failure modes stacked on top of one. X.com is many things but it is not going to be taken offline by a cease and desist letter from X Corp.
The instinct that makes people reach for a mirror is a good instinct. Not wanting to build on a platform that can cut you off is correct. The mistake is thinking a mirror resolves it. It relocates the dependency onto a weaker party and adds a legal single point of failure that the original never had.
What I would actually do
For dead links in old posts, do not delete them. Change the destination to the canonical x.com URL and leave the text alone. The reader who cannot or will not open X is no worse off than they are with a 404, and you stop shipping broken links. It is a find and replace, and for most people it is a five minute job.
For automation, this is the moment to decide whether the feature is worth paying for or worth deleting. If you genuinely need programmatic reads of X content, the official API is the only durable answer and it costs what it costs. If you cannot justify that, delete the feature rather than hunting for the next mirror. The next mirror has the same three failure modes and now a demonstrated precedent pointed at it.
And the general rule I am taking from this: if a capability is load-bearing for your business, it needs to be something you pay a company for under a contract, or something you host yourself. A free unofficial intermediary is fine for convenience and genuinely bad for infrastructure. Nitter was a wonderful thing to use and was never a reasonable thing to depend on, and I say that as someone who depended on it.
Where this is unfair to X, and where I am overreaching
X is not unusual here, and it would be dishonest to write this as though it were. Meta has repeatedly taken scrapers to court. Most large social networks restrict third-party readers and push everyone through the official app where they can be tracked and shown ads. Nitter explicitly stripped ads and tracking, which is precisely the thing a platform funded by ads and tracking will eventually litigate about. The behaviour is consistent across the industry and the outcome here was predictable.
The claims may also have merit. Accessing accounts and session tokens, if that is what happened, is a different thing from reading public pages, and I have not seen the evidence either way. "Open source project gets bullied" is an easy frame and I do not know that it is the right one.
Where I would push back on myself hardest: I have written this as though the lesson is about dependency management, which is the part I can act on. But most people used Nitter to read, not to build. For them there is no lesson and no mitigation, just a thing that worked and now does not, because the platform preferred they have an account. Dressing that up as a stack architecture insight is a little self-serving, and worth naming.
Author
Lukas
@lukcombinator