Video Summary - I Made the World's First "Link Compressor"

Overview

The video critiques traditional URL shorteners and QR code generators and presents an experimental approach to make them work without a database, while improving QR encoding efficiency.

Problems with typical link shorteners / QR generators

Database dependency & security concerns: Shorteners store the full URL in a backend database. The video argues that stored data may be insecure, and that random guessing can sometimes reveal someone else’s shortened links.
Cost & ads: Maintaining the database costs money, so many services show ads before redirecting.
Link persistence risk: If the service shuts down, shortened URLs can become unrecoverable.
QR scanning vs density: For QR codes, a denser QR code is harder to scan.
QR tools require signup or use wrong encoding: Many generators force you to sign up/pay, and the video claims they often use a suboptimal QR format, producing larger QR codes than necessary.
“Easy fix” ignored: The creator argues the inefficiency is avoidable, but many tools don’t care.

Core idea: compress + encode the full URL locally (database-free)

The proposed system aims to:

shorten links,
generate optimal QR codes, and
avoid ads/registration,
while keeping the original URL fully recoverable even if the service disappears.

It’s framed as an experiment, not a polished consumer product—though it “does a pretty good job at QR codes.”

Link compression via redundancy removal (example)

Example: a long NYT Wordle URL is shortened by removing “fluff” like:

protocol (http vs https)
www prefix
index.html suffix (and similar server defaults)

The video notes this can become lossy if removed parts are required. So the solution uses bit flags instead, e.g.:

1 bit for http/https
1 bit for presence/absence of www
compact multi-option encoding for index type (index.html vs index.php, etc.)

Replace text with compact symbols (information-theoretic motivation)

The approach uses the fact that not all URL parts need to be stored verbatim:

TLDs like .com, .net, .org, etc. come from a finite set.
Encode TLDs as small integers (e.g., map .com → 0, .net → 1, … with reserved handling for unknowns).

Big picture: if compression is strong enough, you might not need a database because the encoded output can be short by itself.

It also references theoretical limits tied to information theory / entropy, while noting the approach is mostly a gimmick.

Encoding details: treat URL fragments as numbers

Instead of using a backend database ID, this design puts the “ID” payload as the encoded + compressed URL data.

Key points:

The payload uses an alphabet of 85 characters (letters, digits, symbols, etc.), similar to base-n encoding.
Data is converted from base-85 to binary to reconstruct the URL.
The domain alphabet is only 38 characters; treating it like a number (via base conversion) can save bits/characters.

Adaptive alphabets for the path

For the path portion, the creator describes adaptive alphabets:

split the URL path into segments,
detect which character set fits best (e.g., lowercase letters, decimal numbers),
choose the smallest alphabet that fits,
but pay overhead by prefixing a small “alphabet index” (trade-off between specificity and marker cost).

To avoid overhead, it uses only eight common categories (too many alphabets increases prefix cost).

Compression details: fixed dictionary + Huffman coding

After structural encoding, compression targets repeating character patterns (URL strings aren’t truly random—e.g., titles often contain English).

Uses fixed dictionaries built from real-world link statistics.
Compression described: Huffman coding
- build a Huffman tree from character frequencies
- assign bit codes via tree traversal

Notes:

Huffman coding is most “perfect” when probabilities match powers of two; English/URL distributions don’t match exactly, so efficiency is slightly off.
It mentions arithmetic coding as an alternative, but considers it too complex for limited gains (claims up to ~15% best-case absolute advantage, likely smaller in practice).

Building probability models (data sources)

Probability distributions came from:

~100,000 links from a web crawler (biased toward major sites like Google/Facebook)
1 million links from Reddit (argued to be more representative of what people share)

The creator also claims additional bias exists (Reddit link dominance) and that they adjusted numbers “just a bit.”

Practical performance (and why output can look ugly)

For many longer links, it can reduce length by “a few characters.”
The output can be ugly and sometimes even longer due to:
- structural constraints: only the part after the domain is compressible
- a “13-character deficit” from the start

Unicode handling note

Browsers escape Unicode into allowed alphabets.
Unicode could help (e.g., emojis fit into a larger set), but it’s still considered impractical and mostly gimmicky.

QR codes: main practical win

The creator argues that QR generators often use byte mode even when alphanumeric mode would be smaller.

QR standard modes mentioned:

numbers
alphanumeric symbols
raw bytes
Japanese kanji

Since URLs are typically not kanji and aren’t purely numeric:

byte mode implies base-256 efficiency
link encoding here is effectively closer to base-85

Suggested improvement for other tools

switch link case to uppercase so QR tools can select the more efficient alphanumeric set

But many services keep links lowercase and thereby force byte mode.

Hammer’s QR output

uses the exact QR alphanumeric character set
can produce QR codes that are as small or smaller than those made by competitors using database-driven shorteners

The video explicitly calls out competitors as potentially “cloning open-source tools” and adding subscriptions instead of fixing encoding.

Offline recoverability & tooling

The algorithm/dictionaries are shared (via GitHub, per the video).
An offline tool is provided to generate and decode these compressed links.
If the domain/service (“Hammer”) goes down, the offline tool still allows recovery.

Domain name acquisition / project details

The domain (“Hammer”) was chosen by searching through Cloudflare domain rankings in reverse and checking availability for short (four-letter) domains.
A friend’s follow-up idea is mentioned: a small transformer model that compresses URLs more aggressively, but requires ~300MB model loading and computation to decompress locally.

Sponsor / tutorial content (boot.dev)

The video promotes boot.dev, a hands-on coding learning platform:

courses in Python, Go, TypeScript, and SQL (including databases)
theory + assignments, code in the browser or Linux terminal
automated checking, optional Discord help, optional “AI mentor”
free tier available; premium unlocks interactive lessons
30-day no-questions refund
creator discount code: “portal runner” for 25% off premium
boot.dev QR code shown, generated by the creator’s tool

Main speakers/sources

Main speaker: the video creator (author of the “Hammer” link compressor and QR generator)
Project/tool references: GitHub repositories and an “offline tool” (described as available in the description)
Sponsor: boot.dev

I Made the World's First "Link Compressor"

Key takeaways