URL compressor

Almost every web address you type begins with one of four openings and ends with one of about seven endings. Between them that is up to sixteen characters of pure ceremony, repeated by everybody, all day, on a channel where the cost of a character is real.

Text messages, radio, printed material, a URL read out over a phone: there are still places where an address has to be short enough to survive being copied by a human. The interesting question is not how to shorten a link with a server, which is a solved and slightly boring problem. It is how much shorter an address gets with no server at all.

Twenty eight combinations and twenty six letters

The four openings and the seven endings make twenty eight pairs. Each pair gets a number, so the whole scaffolding of an address collapses into a single digit or two, and what remains is the domain body and the path. An address becomes something like 1.example/pricing.

On top of that sits a second table of twenty six popular destinations, one per letter of the alphabet, each covering a full prefix rather than a domain. The letter y stands in for the whole of a video watch address up to the identifier, w for an encyclopedia article path, r for a forum’s subsection path. When one of those matches, the prefix stops being characters at all and becomes one keystroke.

What the numbers actually were

A forty three character video link came out at twelve characters, a saving of seventy two percent. A forty one character encyclopedia article came out at twelve as well, seventy one percent. Both of those are cases where the single letter table does the heavy lifting.

The ordinary case is more honest. A thirty one character address on an unremarkable dot com came out at seventeen characters, forty five percent, purely from folding the opening and the ending into one digit. That is a large saving for a table that fits on one screen and a program that does no lookups.

Where it stops

Point it at an address whose ending is not one of the seven, and nothing happens at all. A documentation link on a newer domain ending came back uncompressed, because the scheme has no entry for it and refuses to guess. The compression is entirely a function of how well the table predicts the input.

It is a compression scheme rather than a link shortener, so the output travels between two parties who share the table and resolves in no browser anywhere. Growing the table would compress more addresses, at the cost of both ends carrying a bigger dictionary to do it.