URLURL Shortener (Local)

What a hosted shortener actually does

At its core, a shortener does one thing: store a pairing of short code to original URL. When someone visits the short URL, the server looks up the original by code and sends an HTTP redirect. There's no magic — the requirements are a domain and somewhere to keep the mapping.

The choice of redirect status code makes a practical difference. A 301 (permanent) gets cached by browsers, so repeat visits skip your server and are faster — but a browser that cached it keeps going to the old target even after you change it. A 302 (temporary) goes through your server every time, so destination changes take effect immediately and click analytics stay accurate. That's why most shorteners use 302.

// GET /aB3xY
const original = await db.get(code);      // look up by code
if (!original) return res.status(404);

await db.incrementClicks(code);           // analytics
res.redirect(302, original);              // temporary redirect

How to use it

1. Enter a URL to be issued a short code and saved to the list.
2. Review the code-to-URL mapping in the list and copy entries as needed.
3. For a link that opens on other devices, use the base64 token link — the original URL is encoded inside it, so it works without any storage.
4. Clearing browser data removes the list, so export anything you need to keep.

How short codes are generated

There are two broad approaches. Encoding a sequential counter in base62 (0-9, a-z, A-Z) gives short codes with no collisions, but being sequential it lets anyone enumerate other people's links. Generating random strings resists guessing but requires a collision check.

Length follows from how many codes you need: six base62 characters give about 56.8 billion combinations, seven about 3.5 trillion. With random generation, the birthday problem means collisions become common around the square root of the space, so allocate generously and rely on a uniqueness constraint with retry at insert time.

Something easily overlooked is confusable characters. 0 versus O, and 1 versus l versus I, get transcribed wrong by humans — so for codes destined for print, use an alphabet that excludes them. Crockford Base32 was designed for exactly this.

Risks and limits of shortened URLs

• Hidden destinations: users can't see where a link goes before clicking, which is why shorteners get used for phishing. Check untrusted short links with a preview feature — some services reveal the target if you append a +.
• Link rot: when a shortener shuts down, every link it ever issued dies at once. Several services have closed and taken large numbers of links with them. For papers and long-lived documents, use the original URL or a DOI.
• Enumerable codes: sequential or very short codes let someone harvest other people's links by scanning. Shortening a private document-sharing link raises its exposure.
• Tracking: most services record click times, referrers, and approximate locations — worth considering in privacy-sensitive contexts.
• SEO: links passing through a redirect may be treated differently from direct links by search engines. For marketing, a short path on your own domain is preferable.

If you build your own

Self-hosting is simpler than it sounds, and keeping your own domain preserves trust — a real advantage for marketing links. Register a short domain and attach a key-value store.

• Storage: reads vastly outnumber writes, so a KV store (Redis, Cloudflare KV, DynamoDB) fits well.
• Edge execution: a redirect involves almost no logic, so running it at the edge keeps latency low worldwide.
• Prevent open redirects: without validating target URLs, your domain becomes a phishing waypoint. Restrict schemes to http and https, and require authentication to create links where possible.
• Expiry: offer a TTL so links you no longer need don't live forever.
• Reserved paths: make sure the code space can't collide with routes like /api or /admin.

Common uses

• Keeping a personal list of long URLs you open often
• Learning how shorteners work by watching one operate
• Turning a long URL into a base64 token link that needs no storage
• Experimenting with code length and collision probability

Frequently Asked Questions

Can I send the short link I created to someone else?

Not the short code itself. This tool keeps the mapping only in your browser's localStorage, so another person's browser has no record of what that code points to. To share, use the base64 token link or a real hosted shortener.

How does the base64 token link work?

It base64-encodes the original URL and carries it inside the link, so no storage is needed and it opens anywhere. But encoding isn't hiding — anyone can decode it. And when the original is long, the token link can end up longer than the original, so there's no shortening benefit.

Are the URLs I enter sent anywhere?

No, they're saved only to browser localStorage. Note, though, that if you share a base64 token link, whoever receives it can read the original URL — worth considering before distributing sensitive URLs that way.

Will my list disappear if I switch browsers?

Yes. localStorage is isolated per browser and per domain, so another browser, another device, or private mode cannot see it. In private mode it's cleared when the session ends, and clearing browser or site data removes it too.

Is there a limit on how many I can store?

You're bound by localStorage's quota — browser-dependent, typically 5–10MB per domain. Since a URL is tens to hundreds of bytes, that's tens of thousands of entries in practice. Saving fails once the quota is reached, so prune occasionally.

Can short codes collide?

This tool avoids collisions with existing codes when saving. But because storage is per browser, the same code can perfectly well point to different URLs in different browsers. If you need globally unique codes, you need a service with central storage.