DEV Community: Evan Mercer

Handle HTML error pages before parsing a video metadata response

Evan Mercer — Tue, 13 Oct 2026 14:39:45 +0000

A download interface can show Unexpected token '<' even when the user's post link is valid. The metadata endpoint may have returned an HTML login page, an upstream error page, or a proxy response instead of JSON. Validate the HTTP response contract before parsing its body so users get an actionable failure and developers keep the actual cause.

I maintain Twitter Viewer and its twitter video downloader. This article uses a fictional metadata endpoint and a small executable response parser. It describes an interface boundary, not Twitter Viewer's private implementation.

Check status before interpreting a successful result

fetch resolves for HTTP errors such as 404 and 500. A resolved promise only means a response arrived. Code that immediately calls response.json() can hide an upstream 502 behind a JSON syntax error if the gateway generated an HTML page.

Give each kind of failure a stable code. A non-success status is different from a successful response with an unexpected media type, and both differ from a JSON object with missing fields.

export async function readMetadata(response) {
  const fail = (code, message) => {
    throw Object.assign(new Error(message), { code });
  };
  if (!response.ok) fail('HTTP', `Metadata request returned ${response.status}`);
  const type = (response.headers.get('content-type') || '')
    .split(';', 1)[0].trim().toLowerCase();
  if (type !== 'application/json') {
    fail('TYPE', 'Metadata endpoint did not return application/json');
  }
  let value;
  try {
    value = await response.json();
  } catch {
    fail('JSON', 'Metadata endpoint returned invalid JSON');
  }
  if (!value || typeof value !== 'object' || Array.isArray(value) ||
      typeof value.postId !== 'string' || !Array.isArray(value.variants)) {
    fail('SCHEMA', 'Metadata response is missing postId or variants');
  }
  return value;
}

Save this as metadata.mjs. The schema check is intentionally small: it establishes that the outer object can be consumed by a caller. A real application should validate each variant's properties before rendering a link or initiating a transfer. A string with the right property name is not automatically a trusted fetch destination.

This contract accepts application/json with optional parameters, including application/json; charset=utf-8. It intentionally rejects vendor media types. If your API uses a vendor JSON type, add it explicitly to the contract and its tests instead of accepting any header that happens to contain the substring json.

Exercise failures without making a network request

Modern Node.js includes the Response class. A test can construct the exact bad response a proxy might return:

import test from 'node:test';
import assert from 'node:assert/strict';
import { readMetadata } from './metadata.mjs';

const json = text => new Response(text, {
  headers: { 'content-type': 'application/json; charset=utf-8' }
});

test('accepts the expected envelope', async () => {
  assert.deepEqual(await readMetadata(json('{"postId":"123","variants":[]}')),
    { postId: '123', variants: [] });
});

test('classifies status, content, and shape separately', async () => {
  await assert.rejects(readMetadata(new Response('<h1>Bad gateway</h1>',
    { status: 502 })), { code: 'HTTP' });
  await assert.rejects(readMetadata(new Response('<html>Sign in</html>',
    { headers: { 'content-type': 'text/html' } })), { code: 'TYPE' });
  await assert.rejects(readMetadata(json('{')), { code: 'JSON' });
  await assert.rejects(readMetadata(json('{"variants":[]}')), { code: 'SCHEMA' });
});

Save that as metadata.test.mjs and run node --test metadata.test.mjs. No API credentials, social account, or live video are needed. These are response-contract tests, so a platform outage cannot make the test results ambiguous.

Keep diagnostics out of the visible error

For the user, an HTTP failure might warrant “Video lookup is temporarily unavailable; retry shortly.” An HTML response might warrant the same recovery advice while retaining a different internal code. Log the status, response type, request ID, and endpoint name where appropriate. Avoid pasting an entire unexpected HTML body into an error toast: it may contain account details, tokens, or internal infrastructure text.

Once metadata is valid, downloading remains a separate operation with its own response contract. Receiving a list of variants does not prove a file reached the user's device. Native public videos, externally embedded players, and inaccessible posts also require distinct source handling; a generic JSON parsing message should never be the explanation for all of them.

Validate X post URLs before requesting video metadata in JavaScript

Evan Mercer — Mon, 12 Oct 2026 23:09:17 +0000

A pasted social URL is untrusted input. Before a backend tries to retrieve media, it should extract a small, well-defined identifier and discard everything else. This article implements that boundary for public X post URLs in JavaScript. I maintain Twitter Viewer; the parser below is an example of input handling, not a claim that these snippets reproduce its backend.

Parse the URL before matching the path

Matching a full URL with a loose regular expression tends to accept misleading hosts. A string can contain x.com in a username, query parameter, or an attacker-controlled subdomain. Let the URL parser separate those components first.

export function parsePostUrl(raw) {
  let url;
  try {
    url = new URL(raw.trim());
  } catch {
    throw new Error('Enter an absolute post URL');
  }
  if (url.protocol !== 'https:') throw new Error('HTTPS required');
  if (url.username || url.password) throw new Error('Credentials rejected');
  if (url.port && url.port !== '443') throw new Error('Unexpected port');
  const host = url.hostname.toLowerCase();
  const allowed = new Set(['x.com', 'www.x.com', 'twitter.com', 'www.twitter.com']);
  if (!allowed.has(host)) throw new Error('Unsupported host');
  const match = url.pathname.match(/^\/([A-Za-z0-9_]{1,15})\/status\/([0-9]{1,20})(?:\/(?:video|photo)\/[1-9][0-9]*)?\/?$/);
  if (!match) throw new Error('Expected a post URL');
  return {
    author: match[1],
    id: match[2],
    canonicalUrl: `https://x.com/${match[1]}/status/${match[2]}`
  };
}

This intentionally accepts a narrow set of common web links. It does not promise support for every historical Twitter route. Mobile hosts, share wrappers, and links without a handle can be added as explicit cases after they have tests. A rejected unfamiliar route should produce a useful message rather than silently falling through to arbitrary fetching.

Keep the post ID as a string. Large decimal identifiers can exceed JavaScript's safe integer range; converting one to Number may change its value before the request even reaches the server. The handle is useful for a human-readable link but should not be treated as an immutable account identity.

Test deceptive hosts as well as normal links

Save the parser as post-url.mjs, then create post-url.test.mjs:

import test from 'node:test';
import assert from 'node:assert/strict';
import { parsePostUrl } from './post-url.mjs';

test('drops share parameters and keeps the ID exact', () => {
  const result = parsePostUrl('https://twitter.com/example/status/18446744073709551615?s=20');
  assert.equal(result.id, '18446744073709551615');
  assert.equal(result.canonicalUrl, 'https://x.com/example/status/18446744073709551615');
});

test('rejects URLs that merely contain a trusted hostname', () => {
  for (const url of [
    'https://x.com.example.org/example/status/123',
    'https://x.com@other.example/example/status/123',
    'https://other.example/?next=https://x.com/example/status/123',
    'http://x.com/example/status/123'
  ]) assert.throws(() => parsePostUrl(url));
});

test('accepts a media-view suffix but removes it', () => {
  assert.equal(parsePostUrl('https://x.com/example/status/123/video/1').id, '123');
});

Run node --test post-url.test.mjs. These tests do not need an X account or network access. They describe the input contract, so upstream changes cannot turn a basic parser test into an intermittent integration failure.

A valid URL does not imply downloadable media

After parsing, there are still independent outcomes: a deleted post, a private account, a post with no native video, an upstream timeout, and a successful lookup with several variants. Keep these separate in the response model. Returning “invalid URL” for every outcome teaches users to keep editing a perfectly valid link.

For a manual workflow, my twitter video downloader accepts public tweet links and offers available MP4 variants. A third-party embedded player is a different media source; the fact that it appears inside a post does not make it a native X video. Saving a file also does not grant permission to republish it.

Revalidate the boundary on the server

Client validation improves feedback, but a caller can skip the client. Apply the same host and path policy on the server. Prefer passing the extracted ID into a constrained lookup rather than fetching the original pasted URL. If a backend follows redirects or later fetches an upstream media URL, that fetch needs its own destination and redirect policy; validating the initial social URL does not validate a later destination.

Parse a TikTok Profile URL Without Keeping Tracking Parameters

Evan Mercer — Mon, 05 Oct 2026 23:56:25 +0000

People paste profile links from chats, browsers, and share sheets. Those links can carry query parameters that are irrelevant to identifying the account. A small parser should extract a handle from the profile path, reject unrelated hosts, and leave the original URL out of the lookup key.

I built TikStories to accept a public TikTok handle or profile URL and show currently active public Stories. The example below is a standalone parsing exercise, not a copy of the site's internal code. It deliberately handles ordinary profile URLs rather than every redirect or link format TikTok may issue.

Parse the host and path

function profileHandle(input) {
  const value = input.trim();

  if (!value.includes('/')) {
    const handle = value.replace(/^@/, '');
    return /^[A-Za-z0-9._]+$/.test(handle) ? handle : null;
  }

  let url;
  try {
    url = new URL(value);
  } catch {
    return null;
  }

  if (url.protocol !== 'https:') return null;
  if (!['tiktok.com', 'www.tiktok.com', 'm.tiktok.com'].includes(url.hostname)) {
    return null;
  }

  const match = /^\/@([A-Za-z0-9._]+)\/?$/.exec(url.pathname);
  return match ? match[1] : null;
}

The hostname check is exact. A string like tiktok.com.example.org does not pass merely because it contains tiktok.com. The path pattern also avoids treating a video URL or unrelated page as an account profile. new URL() separates the query string, so tracking parameters never enter the returned handle.

Try the cases that matter

const cases = [
  ['@example.creator', 'example.creator'],
  ['https://www.tiktok.com/@example.creator?lang=en&share_id=123', 'example.creator'],
  ['https://m.tiktok.com/@example.creator/', 'example.creator'],
  ['https://tiktok.com.example.org/@example.creator', null],
  ['https://www.tiktok.com/@example.creator/video/123', null],
  ['not a handle', null],
];

for (const [input, expected] of cases) {
  const actual = profileHandle(input);
  if (actual !== expected) throw new Error(`${input}: ${actual} !== ${expected}`);
}

This approach does not resolve shortened links or prove that a handle exists. After parsing, the application still needs to look up the public account and handle empty results honestly. A private profile cannot be made public by changing the URL. If a product accepts more URL forms, add them as explicit cases with tests rather than weakening the host check.

Designing the Empty State When the Thing Users Want Usually Isn't There

Evan Mercer — Tue, 29 Sep 2026 02:30:27 +0000

Some features are empty most of the time by nature: a "live now" section, a sale banner, stories that expire after 24 hours. If the empty state is a blank area with "Nothing here", users read it as broken and leave. The fix is to treat "nothing right now" as the normal case, say so plainly, tell people when to come back if you know, and show the closest useful thing instead. Below is the pattern I use, with a small, framework-free implementation you can adapt.

Three kinds of "empty"

Lumping these together is the root of most bad empty states:

Nothing yet, and that's expected. No live item right now; there will be later.
Nothing, because of a limit. The content exists but can't be shown (private, region-locked, needs permission).
Nothing, because something failed. Network error, timeout, bad input.

Each needs different wording and a different next step. Case 1 needs a fallback, case 2 needs an honest explanation, case 3 needs a retry.

Model it explicitly

Don't let the UI infer the state from items.length === 0. Return a status alongside the data:

// status: "live" | "none" | "restricted" | "error"
function viewState(result) {
  if (result.error) return { status: "error", message: result.error };
  if (result.restricted) return { status: "restricted" };
  if (result.liveItems.length === 0) return { status: "none", fallback: result.recentItems };
  return { status: "live", items: result.liveItems };
}

Show time remaining, not just existence

When live items expire, the most useful single fact is how long each one has left. Round down to whole hours above one hour and show minutes below it:

function timeLeft(expiresAt, now = Date.now()) {
  const ms = new Date(expiresAt).getTime() - now;
  if (ms <= 0) return "expired";
  const mins = Math.floor(ms / 60000);
  if (mins < 60) return `${mins} min left`;
  return `${Math.floor(mins / 60)} h left`;
}

console.log(timeLeft(Date.now() + 5 * 3600e3 + 20 * 60e3)); // "5 h left"
console.log(timeLeft(Date.now() + 42 * 60e3));             // "42 min left"
console.log(timeLeft(Date.now() - 1000));                  // "expired"

Compute it on the client from an absolute timestamp, so a tab left open for an hour doesn't keep showing a stale "3 h left". Refresh the label every minute.

Write the "none" state as information

Bad: No results.

Better: No story is live right now. Stories last 24 hours, so check back later. Here are the most recent videos in the meantime.

The better version says what's missing, that this is normal, why, and what's shown instead. Then render the fallback directly underneath, without making people click a tab.

Keep "restricted" and "error" honest

Restricted: say what the limit is and stop. "This account is private, so its posts aren't public." Don't hint that a workaround exists.
Error: say it's a problem on your side or the network's, keep the user's input in the box, and offer a retry button.

A real example

I use this pattern in TikStories, a free viewer for public TikTok profiles. Most public accounts have no active story at any given moment, so the "none" state is the common one: the page says no story is live, and the Videos tab already holds the account's recent posts, so there's still something to look at. When stories are live, each tile carries the hours left before it expires. Private accounts get a plain "this account is private" message, with no suggestion that anything can get around it.

Checklist

[ ] The API distinguishes none / restricted / error; the UI doesn't guess from an empty array.
[ ] The "none" message says it's normal and, if possible, when to come back.
[ ] A useful fallback renders in the same view.
[ ] Expiring items show time remaining computed from an absolute timestamp.
[ ] Restricted states don't imply a workaround.
[ ] Errors keep the user's input and offer a retry.

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.