Why I Built Another URL Shortener (and Why It Took Longer Than It Should Have)

Originally published at nly.kr Blog.

I didn't set out to build a URL shortener. I set out to shorten one link, for a Slack message, at 11pm, and got annoyed enough by the process that I ended up building nly.kr instead.

The annoyance was simple: every shortener I opened wanted me to sign up first. Or it buried the "just shorten this" button behind a pricing page. I just wanted to paste a URL and get a short one back.

So I opened a blank file and started there — no login, no account, paste a link, get a short one, done.

The part that seemed easy and wasn't

Generating a short code sounds trivial until you're the one dealing with real usage.

My first version just picked a random 6-character string and checked if it already existed. Fine at low traffic.

Then I ran a few tests and started seeing collisions happen when multiple requests arrived at the same time — two requests could both think a short link was available and try to create the same one.

I ended up moving the uniqueness check into the creation process itself instead of relying on a separate availability check.

It's a small change but it's the difference between "usually works" and "actually works."

I also made sure that anything coming from a public request was handled safely — with a service anyone can use without an account, I didn't want to assume every request was trustworthy.

Login-free also means abuse-prone

The moment you remove the signup wall, you also remove one of the easiest ways to control abuse.

Within the first week of quietly testing this on a few Korean developer communities, I saw a small burst of automated requests trying to generate short links in bulk — nothing malicious that I could tell, just someone's script testing what it could get away with.

I ended up using external tools for basic rate limiting and bot filtering instead of trying to build everything myself.

It's not a perfect solution, but it gave me more time to focus on building the actual service instead of spending all my time fighting automated traffic.

QR codes, an extension, and scope creep I don't regret

Once the core shortening flow worked, a few things got added because I kept wanting them myself:

• QR code generation on every short link, because I kept needing to put links on things people couldn't easily type (posters, print materials, presentation slides)
• A Chrome extension so I could right-click a page or a link and shorten it without opening another tab — this came directly from being annoyed at repeating the same steps
• A REST API, mostly so I could automate link creation instead of doing it manually
• Optional accounts for people who do want click stats and link management, without forcing that on everyone else

None of these were part of the original plan.

They're the result of using my own tool enough times to notice what was missing.

Multi-language pages, and the hreflang mess

I wanted the create-short-url page to actually work for people outside Korea too, which meant supporting multiple languages properly.

The site now includes Korean, English, Japanese, Chinese, German, French, Spanish, Vietnamese, Turkish, and Indonesian versions.

Managing many language versions was more tedious than difficult. One missing connection between languages could cause search engines to ignore the whole group.

I ended up creating a small process to generate and check these language connections automatically instead of managing everything manually.

Where it stands now

nly.kr is still a small tool.

It does the one thing I originally wanted (instant shortening, no login) and a handful of things I added because I kept needing them (QR codes, the extension, the API).

I also ended up building a few related tools — a PDF generator, a JSON viewer, a Base64 converter, and a UUID generator — mostly because once I had the foundation in place, adding small useful tools made sense.

I wanted somewhere to point people who needed something quick and free without an account wall.

The documentation, including the API reference, is available here:

https://github.com/nly0000/nlykr-docs

What I learned

The biggest lesson wasn't about URL shortening itself.

It was that removing friction for users usually creates more challenges behind the scenes.

A simple tool that anyone can use still needs to think about reliability, abuse prevention, international users, and long-term maintenance.

I'd still make the same choice today: let people use the tool first, and ask for an account only when they actually need more features.

If you've built something similar, I'd be curious how you handled the abuse and rate-limiting side without a login wall — that's the part I'm least confident I've gotten right.