← rudraansh / projects / leetcode-redirect

LeetCode Redirect live

2026

GitHub Actions · vanilla JS · JSON index

A small utility that turns rudraanshpatel.in/<number> into a direct link to the matching LeetCode problem. Type /1 and you land on Two Sum. Type /2962 and you land on Count Subarrays Where Max Element Appears at Least K Times. Premium problems get a small chooser page instead of a broken link.

No server, no database, no runtime cost. The whole thing is a static site — GitHub Pages serves it for free, and a scheduled GitHub Action keeps the problem index fresh.

user visits /1234 404.html served by github pages parse path fetch problems.json premium? flag check no redirect → leetcode /problems/<slug>/ yes show chooser [leetcode] / [google] non-number path → normal 404
The whole flow runs on the client. Nothing dynamic on the server.
What I built

A vanity-URL pattern for LeetCode problems. Instead of bookmarking long slugs, I can share rudraanshpatel.in/15 in a chat or paste it into notes — and it always resolves to the right problem page. Premium problems show a chooser between Open on LeetCode and Search on Google so the link is never a dead end.

How it works

GitHub Pages serves 404.html for any path that doesn't match an existing file. I treat that 404 page as a router: a small script reads the URL, and if the path is a number, fetches /problems.json — a static index of every LeetCode problem with its id, slug, title, and a premium flag.

If the problem is free, the page does window.location.replace(…) to the real LeetCode URL. If it's premium, the page swaps in a chooser UI. If the path isn't a number, it falls through to a normal 404 message.

The problems.json file is rebuilt periodically by a scheduled GitHub Action, so new problems get added without me touching the repo.

Tradeoffs

Doing the redirect in JS means the URL flashes through the 404 page for a beat before landing on LeetCode. A server-side redirect would be instant, but it would also require a server — and the whole point was to keep this free, static, and zero-maintenance. The flash is a fair price.

The problems.json file is small enough today (a few hundred KB) that fetching it on every visit is fine. If it grows past a megabyte I'll switch to per-problem JSON files or a binary-searchable index.

What I learned

Static + scheduled regeneration is an underrated pattern. You get near-real-time data with zero hosting cost, zero runtime concerns, and your "infrastructure" is one YAML file. The mental shift from "I need a server for this" to "I need a build step for this" opens up a lot of small useful projects.

Also: 404 pages are a more general primitive than they look. Any path-based dispatcher you'd write on a server can be moved to the client this way — vanity URLs, short links, dynamic redirects, even simple lookups.

[try /1] [try /2962] [source]

← back to projects