I maintain Twitter Viewer, including a twitter video downloader for native videos in public X posts. The examples below explain browser delivery choices in general; they are not a description of the service's internal implementation.

A link can navigate even when fetch is blocked

A normal anchor asks the browser to navigate. A fetch asks JavaScript to read a response. Cross-origin servers need to permit that script access through CORS. A video URL may open in a new tab while fetch(url) fails with a CORS error. That difference does not prove the media URL is broken.

<a href="https://media.example.test/clip.mp4" target="_blank" rel="noopener">
  Open video file
</a>

The .test address is a placeholder, not a working video. Substitute a source you control to experiment. The browser may show a player instead of a save dialog, depending on the response and browser behavior. Label the button according to the action you can actually guarantee.

The download attribute is a hint with boundaries

For a same-origin file, a link such as <a href="/exports/clip.mp4" download="clip.mp4">Save MP4</a> is a useful starting point. It does not mean an arbitrary remote server will accept your requested filename or force the same behavior across browsers. The server's headers and the origin relationship still matter.

Do not promise that adding download makes every third-party media URL become a local file. Test your actual response headers, delivery origin, and mobile browsers. A successful desktop test against a localhost file does not exercise the same conditions as a cross-origin production response.

A blob download trades flexibility for resource use

If a server permits fetch access, you can read the response as a blob and create an object URL:

async function saveAllowedFile(url, filename) {
  const response = await fetch(url);
  if (!response.ok) throw new Error(`Download failed: ${response.status}`);
  const blob = await response.blob();
  const objectUrl = URL.createObjectURL(blob);
  const link = document.createElement('a');
  link.href = objectUrl;
  link.download = filename;
  document.body.append(link);
  link.click();
  link.remove();
  // Keep the URL alive briefly for the browser to start consuming it.
  setTimeout(() => URL.revokeObjectURL(objectUrl), 60_000);
}

This is a small-file example. blob() waits for the complete response, so the browser must receive the file before the save action starts. Large media can place substantial pressure on memory or storage, especially on phones. The timeout is cleanup, not a signal that the transfer has completed. For large files, prefer a delivery design that lets the browser manage the transfer rather than buffering the entire asset in application JavaScript.

A server proxy creates new responsibilities

A controlled server can send an appropriate content type and a Content-Disposition attachment header. But proxying arbitrary user-supplied URLs creates a server-side request boundary, operational bandwidth costs, and abuse risks. Restrict sources, validate redirects, and avoid buffering a large response entirely in memory merely to set a filename.

A failed upstream lookup, a blocked cross-origin read, and an interrupted file transfer should have different messages. The first may need the user to check the source post. The second may require a delivery-path change. The third may need a retry after the connection recovers. Keeping those failures distinct is more useful than placing all three behind a generic “download failed” alert.

Install

ffprobe ships with FFmpeg.

# macOS
brew install ffmpeg
# Debian / Ubuntu
sudo apt install ffmpeg
# Windows (winget)
winget install Gyan.FFmpeg

The one command

ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,width,height,r_frame_rate,bit_rate:stream_side_data=rotation:format=duration,size \
  -of default=noprint_wrappers=1 clip.mp4

Example output for a vertical clip (your numbers will differ):

codec_name=h264
width=720
height=1280
r_frame_rate=30/1
bit_rate=2071584
duration=18.466000
size=4812345

Reading it:

• width and height are the stored frame size. Here the video is vertical: 720 wide, 1280 tall.
• r_frame_rate is frames per second as a fraction (30/1 is 30 fps, 30000/1001 is 29.97).
• bit_rate is in bits per second, so about 2.1 Mbit/s.
• size is the file size in bytes; duration is in seconds.

If the rotation line appears (for example rotation=-90), keep reading below.

"1080×1920" is not "1920p"

Resolution labels like 720p and 1080p describe the shorter side of a landscape frame. A vertical 1080×1920 video has exactly the same number of pixels as a landscape 1920×1080 one. It's "1080p, vertical", not a higher resolution. Download pages that list sizes as width×height make this visible: if the first number is smaller, the video is portrait.

A quick check that prints the orientation:

ffprobe -v error -select_streams v:0 -show_entries stream=width,height -of csv=p=0 clip.mp4 \
  | awk -F, '{ print ($1 < $2 ? "portrait" : ($1 > $2 ? "landscape" : "square")), $1 "x" $2 }'

Rotation metadata

Some files are stored landscape with a flag telling players to rotate them. ffprobe shows the stored size, so a clip that plays as portrait can report width=1280 height=720 plus rotation=-90. Players that ignore the flag show it sideways.

To bake the rotation into the pixels so every player shows it correctly (FFmpeg applies the flag automatically when re-encoding):

ffmpeg -i clip.mp4 -c:a copy clip_upright.mp4

This re-encodes the video, so the file changes size and loses a little quality. Only do it when a player you care about gets the orientation wrong.

Sharp-looking but low bitrate

Two files with the same resolution can differ a lot in quality. Bitrate is the better guide. Rough numbers for H.264 at 30 fps:

• 720p: around 1.5–3 Mbit/s looks fine for talking heads; fast motion needs more.
• 1080p: around 3–6 Mbit/s for typical social clips.

A 1080p file at 800 kbit/s will show blocky artefacts in motion, whatever its label says. If you downloaded several versions of the same clip, compare bit_rate and size, not just the resolution.

Checking a whole folder

for f in *.mp4; do
  printf '%s\t' "$f"
  ffprobe -v error -select_streams v:0 -show_entries stream=width,height,bit_rate \
    -of csv=p=0 "$f"
done

Each line is the file name, a tab, then width, height and bitrate separated by commas. Replace the commas with tabs if you want to paste it into a spreadsheet.

Where these files came from

I use this mostly on clips saved with Twitter Video Download, a free tool I make for saving public X video and GIF posts as MP4. It lists the versions a post offers by their width×height, which is where the "is 1080×1920 better than 1280×720?" question keeps coming up. The answer is always in ffprobe: compare orientation and bitrate, then keep the version that suits the screen you'll watch it on.

On paper it's the same product twice. In practice, about half of what I'd learned carried over cleanly and the other half didn't apply at all. This is a note on which half was which, because I suspect it generalises to anyone building "view public content without the login wall" tools for more than one platform.

What carried over

1. Treat the input box as the product

On both platforms, the first thing a user does is paste something, and what they paste is messy: a bare handle, a handle with an @, a full profile URL, a URL from the share sheet with tracking parameters hanging off the end. The first version of any tool like this tends to handle one of those forms well and fail the others.

The lesson that carried over: accept every reasonable shape of input and normalise it before doing anything else. TikStories takes a bare handle (jasonderulo) or a full tiktok.com/@username link, and strips tracking parameters from pasted links before the lookup runs.

2. The lookup shouldn't carry anyone's identity

The principle carried over: a "no login" tool shouldn't quietly borrow someone's login. In TikStories the lookup runs server-side with no cookies and no session attached, so no user's account (and no account of mine) is part of the request; the video itself then streams from TikTok's CDN like any public page. The way I describe it carried over too: be precise about what "anonymous" covers, and don't claim more.

3. Private stays private, and say so up front

TikStories can't open private accounts. A private account's stories are only served to its approved followers, so there's nothing public to fetch. Stating that plainly on the page turned out to be as much a product feature as anything the tool does, because it sets expectations before someone pastes a private account and assumes the tool is broken.

What didn't carry over

1. Most of the time, there's nothing to show

A public X profile nearly always has something on it: posts are persistent. A TikTok account's stories are the opposite: most accounts, most of the time, have no active story. That flips the default state of the product. On X, "empty" is an edge case. On TikTok, "empty" is the normal case.

If you port the X mental model directly, you end up with a story viewer that shows a blank page for most lookups. TikStories instead falls back to the account's recent videos when no story is live, so the page still answers the question the user came with.

2. Time is part of the content

X posts don't expire. TikTok stories disappear 24 hours after posting, which makes "how long is this still here?" a real question that didn't exist on the other platform. Each story tile in TikStories shows the hours left before it expires. It's a small detail, but it's the one piece of UI that had no equivalent in the earlier tool at all.

3. "Can I save it?" means something different

With persistent posts, reading is the whole job. With content that vanishes in a day, the obvious next question is whether you can keep it. TikStories is viewing-only for now, and it keeps no archive: once a story's 24 hours pass, it's gone, and the tool can't bring it back. Being clear about that is more useful than implying otherwise.

The general rule I'd take from this

If you're building the same kind of tool for a second platform, copy the parts that are about people (messy input, honesty about privacy, clear limits) and re-derive the parts that are about content (how often there's something to show, whether it expires, what users want to do with it). The first set is surprisingly stable across platforms. The second set is where the new platform is actually different, and where a straight port quietly fails.

I ended up building a viewer for exactly that kind of content — TikStories — and the expiry turned out to drive almost every design decision in it. This is a write-up of the three that mattered, because the same shape shows up in anything that displays ephemeral data.

1. A timestamp is not enough; show what is left

The obvious thing to render on a story tile is when it was posted. "Posted 6 hours ago" is true, it is easy, and it is almost useless here.

What a reader actually wants to know is how long they have. Those are the same number in different clothes, but only one of them answers the question. "18 hours left" tells you that you can come back tonight. "6 hours ago" makes you do the subtraction yourself, and you have to already know that TikTok's window is 24 hours to do it at all.

So each tile shows the hours remaining rather than the age. It is a one-line transformation of the same field, and it is the single change that made the tool feel different from the other story viewers I tried while deciding whether to build one. Several of them showed nothing at all about time, which means every story on the page looked equally fresh whether it had a day left or ten minutes.

The general rule: for expiring content, render the distance to the deadline, not the distance from the event. The user is standing at the deadline end.

2. The empty state is the common case, so it cannot be an empty page

Here is the thing that catches you out when you build a story viewer: most accounts have no active story at any given moment. Stories are a burst behaviour. Someone posts three in an evening and then nothing for a week.

That means the "no results" branch is not an edge case you handle for completeness. It is the branch that runs most of the time. A viewer that renders a blank panel with "no stories found" is, statistically, a blank panel.

TikStories falls back to the account's recent videos instead. Same input, same page, but when there is no story to show, you still get something that answers the underlying question — what is this account posting? — rather than a dead end. The search was not wasted; it just landed on the ordinary case.

If you are building anything with a sparse primary result, it is worth asking what the second-best answer is, and whether you can show that instead of nothing. The honest version of that question is: what did the user probably want, if the literal thing they asked for does not exist right now?

3. Say plainly what the tool cannot do

Tools in this category have a credibility problem, and it is self-inflicted. Search for a TikTok story viewer and you will find pages promising to open private accounts. They cannot. A private account's stories are only ever served to its approved followers — there is no public version of that content sitting somewhere waiting to be fetched. A page claiming otherwise is either lying or harvesting logins.

I decided early that the limits would be written on the page rather than discovered by the user after wasting five minutes. There are four of them and they are all permanent:

• Private accounts cannot be opened. Not by this tool, not by any tool.
• Expired stories cannot be recovered. Once the 24 hours are up, there is no archive.
• It cannot show who viewed your own story. That list only exists inside the app.
• It is a viewer, not a downloader. No save button.

Writing the limits down costs one short section and buys the only thing that matters in a category full of scams: a reader who believes the rest of the page. It also quietly filters out the traffic that was never going to be happy — people looking for a private-account viewer bounce immediately, which is the correct outcome for both of us.

Where this applies beyond stories

The pattern is not TikTok-specific. Anything with a TTL — a temporary share link, a live auction, a status that clears at the end of the day, a token that expires — has the same three questions sitting underneath it:

1. Are you showing the user the age, when they need the remaining time?
2. Is your empty state the common case, and does it still answer something?
3. Have you written down what the thing genuinely cannot do, before a user finds out the hard way?

None of those require clever engineering. They are just the questions that stop getting asked once you are deep enough in the implementation to have forgotten what the page looks like to someone arriving cold.

I build these small tools outside a day job, so "small enough to keep running" is its own constraint — but the three decisions above cost nothing to keep, which is probably why they survived.

The four states everyone designs for

Paste a valid link to a public post with a video → show a preview and a download button. That's the state every mockup shows, and it's maybe 60% of real traffic.

The states that actually decide whether the tool feels trustworthy

Valid link, no downloadable media. Someone pastes a link to a text-only post. This isn't an error — the link worked fine, there's just nothing to extract. Showing a generic "Something went wrong" here is actively misleading; it makes people think the tool is broken when the input was just never going to produce a result.

Valid link, private or deleted content. The post used to exist, or exists but isn't public. A tool that can't distinguish "I can't reach this" from "this genuinely isn't accessible to anyone" ends up training its users to interpret every failure as a bug report waiting to be filed.

Malformed input. People paste screenshots' worth of surrounding text, a shortened link, a link with tracking parameters, or a URL to the profile instead of the post. The fix isn't "validate strictly and reject" — it's parsing generously and telling people specifically what was missing, not just that the input was "invalid."

Ambiguous media. A post with a video and a quoted post that also has a video. Which one did the user mean? Guessing wrong silently is worse than asking.

Why this matters more than the happy path

None of these states are exotic edge cases — collectively they're a large share of real usage, just spread thin across many small variations. A tool that only handles the golden path teaches people, one bad experience at a time, that it's unreliable, even when the failure was entirely appropriate given the input. The fix isn't more error handling in the generic sense; it's naming each failure precisely enough that the person pasting the link knows whether the problem is theirs to fix or just isn't fixable at all.

I don't think this is unique to link-paste tools — it's the same shape of problem as any interface built around "hand me one piece of input, I'll do the rest." The demo is always the easy 20%. The product is the other 80%.

I went through the list properly in August 2026, because I kept seeing "Nitter is dead" repeated as settled fact and it doesn't match what my browser shows me. Here's what's actually there, and why I think this category of tool is structurally hard to keep alive — which is the more useful question anyway.

What happened in 2024

The short version, from the project's own record rather than from memory:

In late January 2024, X stopped allowing the creation of guest accounts. Guest accounts were the mechanism that let unauthenticated clients pull public content — per the project's maintainer, they were anonymous accounts valid for about a month, created when an older version of the mobile app was launched for the first time. On 28 January it became clear no new ones could be obtained. By 16 February, the maintainer stated on GitHub that all public instances would soon be dead, with no viable path forward that didn't involve account suspensions. The two-word version he posted — "Nitter is dead." — is the sentence that got quoted everywhere afterwards.

That's where most write-ups stop. It's also where the interesting part starts.

It didn't stay dead — the price changed

The repository is not archived. It was created in June 2019, has 13.4k stars, and its most recent commit is dated 13 August 2026 — the day before I wrote this. That is not the commit history of a dead project. And the README now carries a line that explains the whole situation in one sentence:

Running a Nitter instance now requires real accounts, since Twitter removed the previous methods. This does not affect users.

Read that from an operator's point of view. The project didn't find a clever way around the change. It moved the cost onto whoever runs an instance: you now need real accounts, with real suspension risk attached to them, to serve strangers content for free.

"This does not affect users" is true and it's the point. The burden became invisible to the people benefiting from it, which is exactly the kind of arrangement that erodes quietly.

What's actually up, August 2026

Nine public instances are listed on the project wiki. Checking them in a real browser — not curl, which several of them refuse outright, and a 403 to curl proves nothing about whether a human can load the page:

So: not dead, not healthy. A couple of instances run well, several sit behind anti-bot services, and the best-known address is a blank page. There's a community status tracker for exactly this reason, which tells you something — you need a monitoring dashboard to find out whether the thing works today.

For contrast, I measured what X itself gives a logged-out visitor the same day: a profile page returns five to ten recent posts and then stops loading, a single post returns the post and three replies, search and explore redirect to a login screen, and the media tab bounces you back to the profile. The working Nitter instances returned more than that. A volunteer-run instance with an uncertain lifespan currently shows you more of a public profile than the platform does.

Why this category is hard

Four reasons, and none of them are about writing better code.

You're building on a door someone else controls. Any tool that depends on what a platform leaves open to unauthenticated visitors has a lifespan equal to that decision, and you are not in the room where it gets made. The 2024 change is the clean example: nothing about Nitter's code broke. The thing underneath it was withdrawn.

The platform has ordinary reasons to close it. Ad impressions and user identification need a session. Data licensing has become real revenue, and free anonymous access dilutes what you're selling. Scraping and abuse impose genuine costs. You don't need a conspiracy for any of this; you just need a spreadsheet.

Free, anonymous, unlimited endpoints get abused. Whatever you built it for, a public instance will find other users, and their behaviour is what determines how quickly the whole category becomes a target. Individual operators absorb the consequences of a crowd they never met.

The maintainer is a volunteer. No revenue, but real abuse handling, real legal exposure, and a codebase that breaks whenever the platform changes. In my experience this is what actually ends most instances — not a dramatic shutdown, just someone deciding they'd like their weekends back. The 2024 change made this worse in a specific way: it converted a technical problem into a personal-risk problem, because now it's your accounts on the line.

"So what do you use?"

Fair question, and I'll answer the meta-question honestly rather than pretend it wasn't coming.

Disclosure first: I maintain a reader for public X content. So I'm a participant in this category, not a neutral surveyor of it.

I'm not going to write about how it works. Two reasons, both practical:

The first is that a detailed writeup of how any of these tools operate is a recipe. Recipes get followed at volume, volume gets noticed, and the door closes faster for everyone still standing in it — including the volunteer instances above, which are more fragile than I am. I'd rather not speed that up in exchange for a more impressive blog post.

The second is that anything specific I wrote here would have a shelf life measured in weeks. This whole area changes constantly. An article full of details that are wrong by October is worse than one that doesn't have them.

What I will state plainly is where the boundaries are, because that's the part that should be stable and that you're entitled to know:

• Public content only. Protected accounts stay unreadable — that's the account holder's call.
• Read-only. No posting, replying, following, or acting on anyone's behalf.
• No affiliation with X, in any direction.
• When something can't be loaded, it says so instead of rendering an empty timeline.

If you're thinking of building one

Some advice that isn't about implementation, because implementation is the easy part.

Decide in advance what you're willing to carry. Abuse will find a public endpoint and you'll be the one handling it. Legal exposure is yours alone. Every platform change lands on your weekend, and they don't announce them. If you're running it on accounts, understand that you're wagering those accounts, not just some server time.

If you'd still do it knowing all that, go ahead — this category exists because people keep deciding it's worth the trouble. Just make that decision before you write the code, rather than discovering the terms eighteen months in when you're too invested to stop.

Where that leaves things

People will keep building these, and platforms will keep closing the doors they're built on, and in between those two events the tools do genuinely useful work. Nitter has been going since 2019. It was declared dead in 2024, by its own maintainer, and it is still being committed to and still serving pages — on borrowed accounts and volunteer time, to users who mostly don't know either of those things.

That's not a tragedy and it's not a triumph. It's just the actual shape of the thing, which "Nitter is dead" doesn't capture.