Every video download site I tried felt like navigating a minefield — five ad clicks to reach a button that triggers another redirect. So I stopped using them and built a clean local tool that handles TikTok, Instagram, and X in one paste.

No watermarks. No ads. No accounts. Just a URL.

~6 min read · Node.js + React · conceptual deep-dive

The Problem With Every Downloader Site

You find a TikTok video you want to keep. Maybe it's a tutorial, a recipe, a clip you want to share somewhere offline. You Google "download TikTok without watermark" and click the first result. What follows is a ritual:

Pop-up #1 appears. You close it. A second tab opens. You close that. You find the actual download button — but it's fake and triggers another ad. The real button is somewhere underneath a consent banner. You finally click download. It starts… and gives you a watermarked file anyway.

This happens on nearly every popular downloader site. They're monetised almost entirely through advertising, and the UX is designed to maximise your exposure to that advertising — not to help you download a video. The actual download logic underneath all that noise is usually a single API call.

So I asked myself: how hard would it actually be to build a clean version of this for personal use?

What I Actually Wanted

Three things, nothing more:

1

No watermark, always

The tool should try its hardest to get a watermark-free file. If it can't, it tells you — it doesn't quietly give you the watermarked version pretending it's clean.

2

Support the platforms I actually use

TikTok, Instagram, and X (Twitter). Paste any URL from any of these three and it should just work.

3

Zero friction interface

One input, one button. No accounts, no CAPTCHAs, no ads. It runs locally so there's nothing to sign up for.

How It Works — The Conceptual Picture

The tool is split into two halves: a lightweight React frontend and a Node.js backend. The frontend is just the URL input box. All the interesting logic lives in the backend.

Here are the five things that happen the moment you paste a URL and hit Download:

Step 1 — Figure Out Which Platform You're On

The very first thing the backend does is inspect the URL and decide: is this TikTok, Instagram, or X? Each platform has its own URL patterns — including short links, mobile URLs, and regional variants — and the tool checks all of them.

tiktok.com · vm.tiktok.com · vt.tiktok.com

instagram.com · www.instagram.com

x.com · twitter.com · mobile.twitter.com

If the URL doesn't match any of these, the backend rejects it immediately with a clear error before wasting any time trying to fetch something it can't handle. No silent failures.

The backend runs through a short chain: detect → resolve → try providers → cache → serve

Step 2 — Resolve Short Links

TikTok in particular loves to generate short share links likevm.tiktok.com/AbcXyz. These redirect to the full video URL, but the download providers need the real URL to work with. So the backend follows up to five redirects to resolve the final destination before doing anything else.

Step 3 — The Provider Chain

This is the core of the tool. The backend doesn't rely on a single source for the download link — it tries multiple providers in order, and only moves to the next one if the previous failed.

Validated & resolved URL

↓

Provider 1: TikWM API — fast, HD, usually no-watermark

↓ if failed

Provider 2: yt-dlp — catches what TikWM misses, supports all 3 platforms

↓ if both fail on no-watermark

Last resort: watermarked fallback (with a clear warning shown)

↓

✓ Download link returned to frontend

The first provider, TikWM, is a public API that's fast and usually returns an HD, watermark-free file. But it occasionally struggles with newer videos or private content. That's whenyt-dlp steps in — a powerful open-source tool that knows how to extract media from hundreds of platforms, and is updated constantly as platforms change their serving behaviour.

Why yt-dlp as a fallback and not primary? TikWM is faster and returns a clean pre-parsed result. yt-dlp is more capable but adds latency since it runs as a local process and parses raw platform data. Using TikWM first keeps the happy path quick.

Step 4 — The Proxy Download

Here's a detail that actually matters for reliability: the tool doesn't give your browser a direct link to TikTok's CDN or Instagram's servers. Instead, it registers a short-livedsecure token that points back to the Node backend. When you click download, your browser hits the backend's own/api/file endpoint, which streams the video directly to you.

Why does this matter? Direct CDN links from social platforms often include authentication tokens or short expiry times. They also sometimes block downloads when accessed directly from a browser outside the platform. Running the stream through the backend sidesteps both issues — and means the download starts with a clean filename instead of a jumble of CDN parameters.

Step 5 — Caching

Once a video URL has been resolved and a download link extracted, the result is cached in memory for 30 minutes. If you (or someone else on the same local instance) pastes the same video URL again within that window, the backend returns the cached result instantly — no API calls, no yt-dlp process, just the stored answer.

The Result

What this adds up to in practice:

🎯

No-watermark first, always

The tool tries every avenue for a clean file before falling back. The fallback is clearly labelled.

⚡

Fast on repeat URLs

Same video twice within 30 minutes? Instant response from the in-memory cache.

🎵

Audio extraction too

The tool also surfaces the audio-only track when available — useful for saving music from TikTok.

🔒

No external accounts

Runs entirely locally. Nothing to log into, nothing phoning home, no API keys required.

One URL input, three download buttons, zero pop-ups. That's the whole interface.

What's Next

The tool is currently running locally but I'm planning to deploy it oncuriousbit.netlify.app so anyone who wants a clean download experience can use it without having to run Node themselves. The architecture is already production-ready — it's just a matter of pointing it at a hosting environment and wiring up the environment variables.

A few things I'd like to add before making it fully public: rate limiting per IP (to avoid abuse), a simple download history in the UI, and potentially Instagram Stories support which currently needs a different extraction path.

The code is structured as a monorepo — backend and frontend live together, share URL validation logic, and build to a single deployable package. If you want to run it yourself locally, it's a singlenpm install && npm run dev away.

---

Over to you: Have you ever got fed up enough with a broken web experience that you built your own alternative? I'd love to hear what you made — or whether you'd actually use a clean, ad-free downloader like this if it were publicly hosted. Drop your thoughts below or find me on LinkedIn.

Vision models, language models, and most other generative systems are confident-but-wrong some non-trivial fraction of the time. The instinct is to fix that with better prompts, bigger models, or smarter agents. The cheaper move is usually to add a small structured review seam — a thirty-second checkpoint where a human can glance, correct, and move on.

This post is the case study for one such seam, dropped into a build I needed for myself. Of 35 garden photos handed to a vision model,74% came back with correct first-pass labels. After thirty seconds editing a CSV,97% were acceptable to publish. Total API cost:$0.18. Total inference time:~74 seconds at 2.1 sec/photo ongpt-4o-mini. The CSV was the highest-leverage code in the project — and it isn’t really code.

Here’s the story.

The annoyance

It was a Saturday afternoon in early March. I’d come back from a walk around the garden with thirty-five photos on my iPhone — bottlebrush in full red, honeysuckle dripping with rain, a lilly-pilly cluster doing its outrageous pink thing, and at least one inexplicable shot of an old railway station I’d passed on the way home.

I wanted to post a handful of them with consistent little hashtag labels —#bottlebrush,#honeysuckle,#flower — burned into the corner like a quiet caption. Not a watermark, not a filter, just a small readable pill that says “this is what you’re looking at.”

What I didn’t want was to open each HEIC in Preview, draw a text box, fiddle with the font, export, repeat thirty-five times. So I did the only reasonable thing: I wrote a small Python tool that does it for me.

The shape of the pipeline

┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Folder │──▶│ Vision │──▶│ CSV │──▶│ Apply │──▶│ Tagged │
│ photos │ │ provider │ │ review │ │ + pill │ │ output │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
↑
human-in-the-loop seam
--mode propose: folder ─▶ vision provider ─▶ CSV
--mode apply: CSV ─▶ render + pill ─▶ tagged output

The minimal product was easy to describe. Point the script at a folder. For each image — HEIC, JPG, PNG, whatever the iPhone or my camera roll throws at it — open it, figure out what’s in it, draw a small rounded hashtag pill into the bottom-right corner, save the result to atagged_output/ subfolder. No watermark across the centre of the image, no filter or colour grade, no destructive edit to the original, and no making me choose the label by hand when a vision model can have a decent first guess.

That last point is where the design got interesting.

The seam

You could write this as a single command: walk the folder, ask the model, render the tag, done. I tried that first. The first-pass run produced a folder of beautifully tagged images, about a quarter of which were wrong in some quietly maddening way — a daisy called#flower, a fern called#leaves, the railway station called, charitably,#station.

So the script runs in two passes.

--mode propose opens each image, hands it to the vision model, and writes a CSV with five columns:

image_path, label, score, suggested_tag, final_tag

final_tag is initialised tosuggested_tag, but the whole point of the column is that you can edit it. Open the CSV, glance down the list, fix anything obvious —flower becomesmorning_glory,leaves becomesbamboo — save, close. On this batch,9 of 35 rows needed editing (a daisy, the railway station, two ferns, the bamboo, and four generic-flower fallbacks). A thirty-second pass.

--mode apply then reads the CSV row by row and renders the tag using whatever’s infinal_tag. The CSV is the human-in-the-loop seam. It is much cheaper than re-running inference, and it catches the cases where the model was right about the genus but wrong about the species, or just wrong.

Three providers, one interface

I didn’t want to commit to one vision model — the price/quality trade-offs are too lively right now. The script supports three providers behind one interface, picked via--provider local|openai|xai.

Local CLIP. HuggingFace’sopenai/clip-vit-large-patch14 against a fixed candidate list. Free, offline,~0.4 sec/photo on an M3 Pro. The cost is breadth: anything outside the candidate list collapses to the nearest match. CLIP doesn’t know what a bottlebrush is unless I tell it the word.

OpenAI.gpt-4o-mini by default, with an opt-in--high-accuracy flag that retries low-confidence cases (under 0.72) ongpt-4o.~2.1 sec/photo, ~$0.18 for the 35-photo batch. Open-ended labels — howbottlebrush,honeysuckle,fern, andberries ended up in the CSV rather thanflower,flower,leaves,fruit.22% of the batch tripped the retry threshold and went togpt-4o.

xAI Grok. Same OpenAI-compatible client, pointed atapi.x.ai withgrok-2-vision-latest. Useful if you’re already on the x.ai stack or want a different model family’s vote.

The mental model: local CLIP for batch-of-a-hundred-photos-on-a-flight, OpenAI as the daily driver, and the high-accuracy retry for exactly the case where the model says “flower” with 0.55 confidence and I want it to look harder before I have to.

The blue morning glory below is what generic labels look like in practice — still a decent fallback, just unspecific. The model wasn’t wrong; it just wasn’t curious.

Two small touches

Two design choices are the difference between “the script works” and “the output looks intentional.”

Style-aware contrast. The pill needs to be readable on both a bright sky and dark foliage. The script crops the bottom-right region of the image, measures the mean luminance using the standard Rec. 709 weights, and flips the colour scheme above or below a threshold:

defstyle_aware_colors(img):w,h=img.sizecrop=img.crop((int(w*0.68),int(h*0.80),w,h))r,g,b=ImageStat.Stat(crop.convert("RGB")).mean[:3]luminance=0.2126*r+0.7152*g+0.0722*bifluminance<140:return(255,255,255,245),(0,0,0,95)# white text, dark pillreturn(0,0,0,245),(255,255,255,95)# black text, light pill

Eight lines of PIL. In this batch every photo sampled dark — gardens are mostly green and shadow in the corner — so every output got the dark pill. The bright-pill branch is still there, waiting for a photo with sky or a light wall in the corner.

Save with fallback. HEIC writes occasionally fail for reasons that aren’t worth diagnosing in a personal tool. The save function tries the original format first; if PIL throws, it quietly drops to JPEG with the same filename stem. Eight more lines. On this batch,3 of 35 fell back to JPEG. Without the fallback those three would have been a stack trace and a half-finished folder. With it, thirty-five of thirty-five made it through.

What I’d add next

Multi-tag support, so a photo can be#lorikeet #bottlebrush when the bird showed up in the bottlebrush. EXIF preservation through the round-trip — right now PIL strips most of the metadata, which I don’t love. A tiny review UI to replace the CSV step, either a Tkinter window or a one-page localhost app. Smarter candidate lists for the local provider, scoped by season or geography — Sydney summer has a different vocabulary than European spring.

None of these are urgent enough to displace “the script already does what I wanted.”

Closing observations

Three lessons that generalise beyond this script.

Human-in-the-loop is cheap and underrated. The CSV seam between propose and apply takes thirty seconds per batch and saves me from confidently wrong outputs. For any task where a model is confident-but-wrong some non-trivial fraction of the time — RAG, codegen, moderation, enterprise copilots, agentic workflows — a structured review step pays for itself almost immediately. The CSV doesn’t have to be elegant. It has to exist.

Pluggable providers are worth the small abstraction tax even on personal tools. I went from local CLIP togpt-4o-mini to Grok in the space of one afternoon without rewriting the rendering code. The interface is(client, model, image) → (label, score) and that’s it. Once you’ve paid that cost once, you can keep up with a fast-moving model market essentially for free.

Small touches decide whether a script feels finished. Luminance-aware contrast and a save-format fallback don’t change what the tool does; they change how the output reads.

The model wasn’t the product. The seam was.

A short reel of the tagged photos in the wild:Instagram story.