Why People Are Leaving Twitter and Looking at Nitter Instead
Nitter shut down in mid-2023 and most of its public instances went with it. The shutdown wasn't sudden — it started with Twitter cracking down on API access and forcing sites that pulled tweet data to either pay for official API keys or stop working entirely. Nitter's creator, zedeus, released a final statement and pulled the codebase offline. That's when a lot of Twitter users realized they had no backup plan for browsing Twitter without giving Meta their data. Before Nitter disappeared, there were other Twitter alternatives people tried. Flixter was one. Twidere was another. Both had issues. Flixter's developer eventually stopped updating it, and Twidere shifted toward a paid model that alienated its free user base. When Nitter finally went dark, the search for a replacement intensified. What emerged was a wave of self-hosted instances popping up on GitHub, some of them being run by people who didn't fully understand the implications of hosting a service that parses Twitter content. Here's the problem with most Twitter front-end alternatives that showed up after the shutdown: they still rely on scraping Twitter. Scraping isn't illegal, but it's a gray area Twitter actively fights. Some of these alternative instances started injecting ads or tracking scripts into the pages they served. That defeats the entire purpose of using a privacy-focused frontend. You traded one tracking problem for another.
I ran a self-hosted Nitter instance for about two years. The setup itself was straightforward — clone the repo, configure your environment, point it at Twitter's old guest API endpoint, and you're done. The real issue came when Twitter changed their anti-scraping measures. The instance would work fine for weeks, then suddenly start returning empty results. The workaround was switching between different instance endpoints and checking GitHub issues for the latest working API endpoints. It took maybe ten minutes to swap out a broken endpoint for a working one, but it meant constant maintenance. The privacy concerns that surfaced with Nitter weren't really about Nitter itself in its original form. The original project was intentionally minimal — no cookies, no tracking, no account required. The concerns emerged because some alternative implementations of the same concept were less careful. A few hosted instances started logging user data, including IP addresses and search queries. Since anyone can deploy a Nitter-style frontend, there was no central authority verifying what each instance did with metadata. That's the core issue: the architecture assumes trust in whoever hosts the instance, and there's no way to verify that trust remotely. There's also a technical limitation most people don't mention. These frontends can only show publicly available content. Private accounts, blocked users, and content behind Twitter's new verification walls simply don't appear. If you're trying to monitor a specific account that requires login or has restricted visibility, a Nitter-style frontend won't help. You'd need a full browser session with authenticated cookies, which reintroduces the privacy tradeoff you were trying to avoid in the first place.
One edge case I encountered regularly: Twitter's rate limiting on guest API calls. If you refreshed a profile page too quickly or queried too many profiles in a short span, the instance would return errors. The solution was adding request delays and spreading lookups across different instance endpoints. Running your own instance actually reduced this problem since you control the request frequency, but it also means you're the one responsible for handling Twitter's blocking when it inevitably happens. For most people who want something that works without maintenance headaches, the options are thinner now than they were two years ago. The original Nitter codebase is archived. Some community forks exist on GitHub, but none have reached the same level of stability or adoption. The alternatives that remain generally fall into two categories: self-hosted solutions that require technical comfort, or third-party services that may or may not respect your privacy depending on who runs them and where their servers are located. If you decide to run your own instance, you should know the ongoing costs. Server hosting, domain registration, and the time spent updating endpoints when Twitter changes their infrastructure again. My personal instance ran on a $5 per month VPS and required maybe thirty minutes of attention per month for updates and troubleshooting. That's not nothing, but it's less than the cost of a Twitter subscription for most people.
Get the Full Details
There's no perfect solution here. Twitter's business model depends on collecting data, and any tool that circumvents that collection will face resistance. The alternatives that exist are fragile by design — they depend on reverse-engineering an API that was never meant to be accessed from third-party clients. That fragility is the real privacy concern, not the code itself. When Twitter decides to close a door, your access disappears with it.
