Why Nitter Still Has Working Instances After the Takedowns

A familiar X link can still trigger the old Nitter habit: strip away the noisy interface, open a lightweight page, and read without signing in. The surprise in September 2026 is that Nitter looks both dead and strangely busy. The official project is paused, its main instance is offline, and its code repository—the version-controlled home for the project—is read-only. Yet the community-maintained directory behind this story has more entries marked working than many readers saw immediately after the takedown wave. As of September 5, 2026, that does not mean Nitter has officially returned: X Corp sent cease-and-desist letters on August 24, nitter.net went offline on August 25, and the repository was archived on August 26. (nitter.net)

The natural question is: why are Nitter instances still working after the official takedown? The answer begins with a distinction that is easy to miss: Nitter is software, while nitter.net was only one hosted copy of that software.

One name, many servers

Nitter is a frontend—the part of an application you see and click. More precisely, it is a server-side frontend: the server fetches data and builds the page, rather than asking your browser to run X’s JavaScript, the programming language used for interactive behavior on web pages. An instance is one independently hosted copy of that service. The original project was designed around no JavaScript, no ads, RSS feeds, and a server that keeps the browser from talking directly to X. (github.com)

RSS, or Really Simple Syndication, is a machine-readable feed format. That small detail made Nitter useful beyond casual browsing: a feed reader could follow a public profile without opening the X interface at all. A cache—temporary storage for recently fetched results—reduces repeated requests, which is why deployments commonly use Redis or its community fork Valkey.

your browser ── pages, images, RSS ──> Nitter instance ── authenticated requests ──> X
 │
 └── cache: Redis or Valkey

This diagram explains the apparent contradiction. Shut down one instance and the software can still be compiled elsewhere. The hard part is not drawing the page; it is maintaining a working path to X.

The bottleneck moved upstream

Nitter’s first major collapse was an access problem. In January 2024, X removed the guest-account application programming interface, or API, that had let services request public data using temporary guest credentials. A guest credential is not a normal user login; it is a short-lived identity issued for automated access. Once that route disappeared, the Nitter code could remain online while its timelines stopped loading. The project documentation now says that running an instance requires real accounts, even though ordinary visitors do not need to log in. (github.com)

There was a brief recovery. On February 6, 2025, the maintainer announced that nitter.net was back after an authentication replacement, while warning that a large public instance was difficult and expensive to operate. That sentence explains much of the current pattern: small operators can keep a copy alive, but a popular public host concentrates every request, every limit imposed by X, and every complaint in one place.

Why new hosts still appear

Open-source software has a long memory. Nitter’s original code is released under the GNU Affero General Public License version 3, or AGPLv3, a copyleft license built to keep source available as people study, modify, and run it. A fork—an independent copy of a project—can preserve an older working build, add a patch, or change how requests are distributed. A legal notice can pressure an operator, but it cannot instantly erase every copy already downloaded.

The ecosystem is also wider than the official repository. The original Nitter project is written in Nim, while newer projects such as teapot implement a similar privacy-focused X frontend in Rust, another programming language. They can offer familiar features such as RSS feeds and pages without third-party JavaScript while using a different codebase and deployment model. That means a list of working Nitter instances may include the original software, forks, and compatible rewrites rather than one perfectly uniform fleet.

Some operators also publish through privacy networks such as Tor, an anonymity network, or I2P, a separate privacy-oriented overlay network. Others place a human-verification challenge or proof-of-work challenge in front of the service. Proof of work, often shortened to PoW, makes a browser spend some CPU time before it can continue. Those defenses may reduce automated abuse, but they can also make a service slower, less accessible, or unusable without JavaScript. (nitt.tr)

Working is a moving target

A directory’s labels describe different kinds of success:

A rate limit is a traffic ceiling imposed by a service. It does not necessarily mean the host is broken; it may recover after a waiting period, reduce what it serves, or switch to another account. Search, media, profile timelines, and RSS can also fail independently because they do not all use the same server requests.

That is why a public status page is better treated as a weather report than a warranty. One host can pass a check in the morning and show an error by lunchtime. Another may work through Tor but fail over the regular web. The list can grow while the average experience remains fragile.

Privacy has a boundary

Nitter removes a lot of direct exposure to X. Your browser does not need to load X’s JavaScript, advertising code, or tracking scripts, and the instance fetches the content on your behalf. That is meaningful privacy protection, but it is not anonymity. A public instance can see your network address and the pages you request, while X can see the instance’s requests.

Authentication adds another trust boundary. A session token is a credential that lets software act like a logged-in account. Public operators need some form of authenticated access to retrieve data, so their security practices matter even when users never enter a password. A private instance gives you more control, but it also makes you responsible for updates, logs, backups, abuse controls, and keeping credentials out of configuration files or public repositories.

The afterlife is real, but it is not stable

More working entries after the takedowns are not proof that the official service has returned. They show that the project has split into layers: a paused upstream repository, independent hosts, forks, rewrites, and directories that keep discovering what still responds.

The most durable use cases are likely to be modest ones: reading a profile, opening a specific post, or subscribing to an RSS feed. Large public instances face a much harder job because they must absorb everyone else’s traffic while managing caches, authentication, rate limits, and legal pressure. Nitter’s maintainer had already described large public hosting as difficult and expensive before the latest shutdown.

As of September 5, 2026, Nitter is best understood not as one website waiting to come back, but as a pattern that people can reproduce. The center has stopped moving; the edges are still flickering.