DEV Community: Evan Mercer

What a no-login viewer can and can't hide from the platform

Evan Mercer — Tue, 22 Sep 2026 23:53:43 +0000

"Anonymous" is the word everyone reaches for when describing a tool that shows public social media content without an account. I use it too, for TikStories, the small TikTok story viewer I maintain. But the word covers two separate requests with different privacy properties, and it's worth pulling them apart, because the honest answer to "can TikTok see me?" is "partly, and here is which part."

Two requests, not one

When you paste a username into a viewer like this, two different things happen:

The lookup. Something has to ask TikTok "what stories and videos does this public account have right now?" and get back a list of items with their URLs and timestamps.
The playback. Once you pick a story, the actual video bytes have to travel from a server to your browser.

Each of these requests has its own sender, and the privacy question is really "who is the sender, and what do they carry?"

The lookup: a server with nothing attached

In TikStories the lookup runs server-side. The server asks for the public account's data carrying no cookies and no session — no TikTok account of mine, and obviously none of yours, because you never gave the tool one.

What that buys you:

TikTok doesn't receive your login cookie for that request, because it isn't coming from your browser.
Nothing about the lookup is tied to a TikTok account, so it can't land in a "recently viewed" list or a story-viewers list on the account owner's side.
Your own TikTok recommendations aren't nudged by the lookup, since no account is attached to learn from.

What it doesn't buy you: the tool's server still made the request. Whatever TikTok logs about server traffic, it logs about that server, not about nobody.

The playback: direct from TikTok's CDN

This is the part people tend to assume is also hidden, and it isn't. Once a story or video is on screen, it streams straight from TikTok's own CDN into your browser, exactly as it would on any public TikTok page.

That means the CDN request comes from your browser, so it carries your IP address and ordinary browser headers, like any image or video you load from any website. It does not carry a TikTok login, because the media URL is a plain CDN link, not a request made from inside your logged-in TikTok session.

Why not proxy the video too?

The obvious "more private" design is to route the video bytes through the tool's own server, so the CDN only ever sees the server. TikStories doesn't, and the trade-offs are worth spelling out:

Cost and speed. Video is the heavy part. Proxying it would mean every byte of every story passing through the server twice. For a free tool with no query limit, that trades a small, well-understood privacy gain for a much slower, much more fragile service.
It moves the trust, it doesn't remove it. A proxy hides your IP from TikTok's CDN by showing it to the proxy operator instead. For most people, "a CDN that serves half the internet's short video sees a request" is not a worse outcome than "a stranger's side project sees every video you watch."
It invites the wrong expectations. A proxy makes a tool look like a privacy product. This one isn't. It's a way to read something public without being forced to sign in first.

A way to explain it to users

The one-sentence version I've settled on:

The lookup carries no account, yours or mine; the video plays from TikTok's CDN like any public page, so it sees an ordinary request from your browser, without a login attached.

It's less catchy than "100% anonymous," but it holds up if someone checks the network tab, which is the test any privacy claim should pass.

The limits that follow from this

Because the whole design is "read what's already public, without a session," a few things are simply out of reach, and I'd rather say so than have people discover it:

Private accounts can't be opened. Their stories are only served to approved followers; there's no public request that returns them.
Expired stories are gone. Stories disappear 24 hours after posting and nothing is archived, which is also why each tile shows the hours left.
Your own story's viewer list only exists inside the TikTok app, tied to your account.

If you're building anything in this category, whether for TikTok, X, Instagram or anything else with a login wall in front of public content, I'd suggest writing down your own version of those two requests before writing the word "anonymous" on the landing page. It makes the copy more honest and the support inbox quieter.

Handing several files to a browser user: zip or not

Evan Mercer — Mon, 21 Sep 2026 17:08:25 +0000

If your web tool produces exactly one file, you are fine. Content-Disposition: attachment, one click, done.

The moment it produces several files, you have a decision to make, and both options are worse than you expect.

Option A: trigger N downloads

The obvious approach is to create N anchors and click them in a loop.

for (const file of files) {
  const a = document.createElement('a');
  a.href = file.url;
  a.download = file.name;
  a.click();
}

This works in a demo with two files and degrades badly after that.

Chrome treats a burst of programmatic downloads from one gesture as suspicious. The first one goes through; somewhere after that the user gets an "allow multiple downloads?" prompt, and if they miss it or dismiss it, the rest vanish silently. Your code has no idea. There is no error, no rejected promise, nothing to catch — the downloads just do not happen.

Safari on iOS is stricter still. A download not tied closely to a real user gesture tends to be dropped, and looping over anchors puts you well outside "closely".

You can paper over this with delays between clicks, and people do. It is a heuristic fighting a heuristic, and it breaks whenever the browser retunes the rule.

Option B: zip them server-side

One request, one file, one download. No multi-download prompt, no gesture heuristics, works the same on desktop and mobile.

The cost lands on the user instead. They now have an archive, and on a phone that means finding it, opening it, and extracting it — which on iOS is a real detour, and for someone who only wanted one of the images inside it is a bad trade.

There is a server cost too: you need every file in hand before you can send the first byte, or you need to stream the zip as you go, which rules out knowing the total size up front.

Where the line actually falls

After shipping both, the rule I ended up with is not about file count. It is about whether the files are one thing.

Images from a multi-photo post: zip. Four photos posted together are a set. Nobody wants the third one alone, the names are meaningless individually, and they are small enough that the archive is not a burden. One download, one folder, order preserved.

Video clips from a post with several videos: separate. A post with three clips is usually three separate things, they are large, and most people want one of them. Zipping forces someone who wanted a 4 MB clip to pull down 60 MB and unpack it to get at it.

That is the actual split in X Video Downloader, the small tool I maintain for saving public media from X: image carousels come back as a single archive, multiple video clips come back as one file each. It looks inconsistent in a feature list. In use it is the difference between "that did what I meant" and "why did it do that".

The bit that is easy to miss

Whichever you pick, decide what happens when the user only wants one item — and make that path exist. For a zip, that means the page still needs a per-file link next to the bundle. It is the cheapest thing in this whole post to build, and the one people reach for most.

The general version: "several files" is not one problem. It is two, and the shape of the files tells you which one you are looking at.

Watching TikTok Stories Without the App: What "Anonymous" Actually Means

Evan Mercer — Sat, 19 Sep 2026 11:40:25 +0000

Someone sends you a TikTok link. You don't have the app installed — or you deleted it a while back — and TikTok answers with a full-screen wall asking you to open it in-app or sign in. The post itself is public. Nothing about it requires an account. The wall is just friction between you and something anyone could already see.

I ran into this often enough that I built a small tool for it: TikStories. Paste a public username or profile link, and it shows you the account's active stories — each one tagged with how many hours are left before it expires — plus their recent videos when nothing is currently live.

Why "recent videos" matters as much as the story viewer

Most story-specific viewers I tried before building this have the same failure mode: check an account, no story is running right now (the normal case, not an edge case), and you get an empty page that looks broken. That's a bad answer to the question someone actually came with, which is usually closer to "what has this account been posting" than "show me literally only the disappearing content."

So when there's no active story, TikStories falls back to the account's recent video grid instead of a blank screen. The page still answers something.

What "anonymous" means here, concretely

The lookup is a plain server-to-server request — no login, no cookies, no session tied to a TikTok account of mine or yours. Once a story or video is actually on screen, playback streams straight from TikTok's own CDN, same as any public page would load it. I can tell you exactly what the lookup itself sends; I can't audit what TikTok's servers do with any given request, and I'm not going to claim otherwise.

It also only works on public accounts, by construction — a private account's stories are served to its approved followers and nobody else, so there's nothing for a tool like this to fetch. That's not a limitation to work around, it's the same boundary the platform itself enforces.

Free, no account needed on either end, no query cap. Built and maintained by me as a side project, same shape as a couple of other small tools I run for reading public content on other platforms without a login wall in the way.

Show DEV: X Video Downloader — a single-purpose video/GIF/image saver for X

Evan Mercer — Wed, 16 Sep 2026 14:21:36 +0000

I keep a small folder of single-purpose web tools I've built for myself over the years, and most of them never see the light of day. This one did, because enough people kept asking me the same question that I figured it was worth cleaning up and sharing.

The problem

Someone posts a video, a GIF, or a set of photos on X (Twitter), and you want to keep a copy — for a write-up, a backup, or just because the post might get deleted. X doesn't give you a "download" button for any of this. Your options end up being a browser extension you have to trust with a lot of permissions, a sketchy site full of redirect ads, or digging through devtools for the raw media URL by hand.

What I built

X Video Downloader is a single page that does one thing: you paste the link to a public X post, and it surfaces the downloadable video, GIF, or image carousel from that post as an MP4 (HD or SD, depending on what the post itself has available) or the original images.

A few constraints I kept on purpose:

No login, no account. Nothing to sign up for, nothing of yours stored.
Public posts only. It can't touch anything behind a login wall, and it isn't meant to — that's not a bug to report, it's the boundary.
One job. No audio extraction, no Space recordings, no bulk/batch mode. If you need those, I have a separate, more full-featured tool for that; this one is intentionally the stripped-down version.

Why a separate tool instead of a feature flag

I already maintain a more full-featured X downloader that also handles audio conversion and Space recordings. I built this one anyway because most visits to that tool are people who just want a video or a GIF, fast, without wading through options they don't need. Splitting it into its own single-purpose page made the common case faster and the page itself simpler to maintain.

What's next

Mobile-friendliness and load speed are the two things I keep iterating on, since most traffic comes from someone on their phone trying to save a clip they just watched. If you try it and hit something that doesn't work on a specific post, I'd genuinely like to hear about it.

Saving X (Twitter) Space Recordings as MP3 Files

Evan Mercer — Sun, 06 Sep 2026 11:09:19 +0000

X Spaces are ephemeral by design. Once the host ends a Space, the audio sticks around for a while as a recording inside the X app, but there's no first-party way to pull that audio out and keep it as a normal file. If you want to relisten offline, drop it into a podcast app, or archive a conversation you were part of, you're stuck replaying it inside the app every time.

Why this bugged me

I run a couple of small tools around X (Twitter) content — mainly a video downloader for regular tweets — and kept getting the same request from people using it: "does this work for Spaces too?" It didn't, because a Space recording isn't a video, it's a separate audio stream with its own delivery mechanism.

So I built a dedicated Space downloader that handles just that case: paste the link to a recorded (finished) Space, and it converts the audio into a downloadable MP3.

What it does and doesn't do

Works on Spaces that have already ended and are still available as a recording.
Does not work on a Space that's currently live — there's no finished audio to fetch yet.
Output is a plain MP3, so it plays anywhere: podcast apps, a phone's default player, whatever you use for audio.
No account or app install required on either end.

The actual use cases I see

Founders/teams doing recurring AMAs who want an audio archive outside of X.
Listeners who caught a good Space live and want to relisten during a commute without streaming it.
Journalists or researchers who need a durable, offline copy of a public conversation for reference.

It's free to use, and I built it as a companion to the video downloader rather than folding audio extraction into an already-busy tool. If you've hit the same "I want this Space as a normal file" wall, it's here: https://twittervideodownload.pro/twitter-space-downloader

Happy to answer questions about format support or edge cases in the comments.

Show DEV: read public X profiles, threads and media without an account

Evan Mercer — Thu, 13 Aug 2026 15:00:43 +0000

Someone drops an X link in a group chat. You tap it, and instead of the post you get a login
screen. The post is public. You just can't read it.

That happened to me often enough that I built a way around the reading part, and then put it
online for anyone else who wanted it: twitterviewer.net. I'm the
person who makes and maintains it, so treat this as a maker's introduction rather than a review.

Why it exists

I read a lot of links I never chose. Research notes, group chats, search results, a citation in
an article — someone else decided the link was worth sharing, and I just want to see what's on
the other end. Making an account to read a single post always felt like a bad trade, and I
didn't want to be logged in while I was just skimming.

So I made myself a reader. It stayed a personal thing for a while, then it seemed silly not to
share it. It's still a side project: evenings, weekends, one person. That shapes what it does —
everything in it started as something I wanted for myself.

What it does

Reading

Look at an account. Someone recommends an account and you want to see what it actually
posts before deciding whether it's worth following anywhere. The
profile viewer shows the profile, the bio
and recent posts.

Read a post with its replies. Half the time the replies are the point — a claim gets
corrected, or the context arrives three replies down. Paste the post URL and you get the post
together with its reply thread.

There's a shortcut for both: take any x.com or twitter.com URL and swap the host for
twitterviewer.net. The rest of the path stays the same, so
x.com/someone/status/123 becomes twitterviewer.net/someone/status/123.

Just the images and video. If you're looking at an illustrator or a photographer, the text
is noise. The media viewer gives you a photo and video wall for an account and nothing else.

Find an account. You remember the name but not the handle, or there are four accounts with
almost the same handle and you need the right one. Search by name or handle.

Saving media

Video. Paste a post URL, wait for the preview, and
download the MP4. When X serves more than
one resolution, you pick which one you want.

GIFs. This one surprises people. X doesn't store GIFs as GIFs — an uploaded GIF becomes a
looping, silent MP4 — so a plain download hands you an .mp4 no matter what the post looked
like. The GIF downloader converts it back
to an actual .gif file, or you can keep the MP4 if that's what you were after.

Two odd ones

Account location. Some accounts expose location information in their "about this account"
details. The location checker pulls that up for a public account. It's a small thing, but if
you're trying to work out whether an account is who it says it is, it's one more data point.

Community member lists. The
communities exporter takes an X Community
URL or ID and gives you the member list as CSV or Excel — handle, display name, verified flag,
role (admin / moderator / member) and profile URL. It caps at 1,000 members and a full export
takes around five minutes.

There's also an entry point for AI agents, so an agent can read this content without an X
account of its own. I'll write that up separately; it's not something you need to care about
if you're just here to read a post.

What it doesn't do

Public content only. Protected accounts aren't visible, and that's deliberate — a locked account is locked.
Read-only. You can't post, reply, like or follow. It's a reader, not a client.
No connection to X. It isn't an official product, there's no partnership and no endorsement. It's a hobby project by someone who is not X.
It doesn't always work. Sometimes a page just won't load its content. When that happens you get told so rather than a blank page, but "read this later" is the honest answer some of the time.
Downloaded media isn't yours. The copyright stays with whoever made it. Saving something for reference and reposting it as your own are different things.

Free, and it doesn't want your account

No signup, no login, no payment. There's also no account system on my side, which means there's
nothing for you to hand over — I'm not asking for X credentials and there's nowhere to put them.

If you try it

If a page won't load, or there's something you keep wanting it to do and it doesn't, tell me in
the comments. One person maintains this, so the list of what gets fixed next is mostly whatever
people actually complain about.