The Telegraph Clerk's Dilemma: On the Deliberate Brevity of the Early URL
Before the web had URLs, it had a different kind of addressing problem. In the mid-19th century, the telegraph network was stitching the world together, and with it came a unique challenge: how to route a message to a single person among millions, using only the clattering, expensive medium of Morse code. The solution was the telegraphic address, a precursor to our modern URL, and its constraints feel hauntingly familiar to anyone who has ever wrestled with a character limit or a cumbersome URI.
Companies and individuals would pay for a short, memorable address—often a single word—registered with the central telegraph office. ‘Smith London’ would suffice to get a message to a specific Smith in London, much like ‘example.com/product’ directs us today. This was an early, forced exercise in information architecture. The address wasn’t just an identifier; it was a costly, performative piece of real estate. Every additional character in a telegram cost money, so the address itself had to be ruthlessly efficient. Brevity wasn't just a style choice; it was an economic and functional necessity.
This historical pressure mirrors a foundational tension in URL design. The early web developers, working with limited bandwidth and user patience, instinctively understood the telegraph clerk’s dilemma. They created short, hackable URLs. You could often deduce the structure of a site by reading its address bar; to navigate to a new section, you might simply type it, like a telegraph clerk guessing an address. The path was the interface.
But then, as with the telegraph, the scale changed. We weren't sending simple messages to a known correspondent; we were building vast, dynamic catalogs. The elegance of the short, logical URL began to buckle under the weight of databases, sessions, and tracking parameters. We ended up with the digital equivalent of a long, rambling telegram full of instructions: ‘https://www.example.com/shop/category/product.php?id=123&sessionid=5678&source=newsletter’. The address became a command script, not a readable signpost.
The modern push for ‘clean’ or ‘semantic’ URLs is, in a way, a return to the telegraphic ideal. It is a deliberate act of imposing brevity and clarity onto a system that has no technical need for it. A well-structured URL is a courtesy. It is a functional artifact that respects the user’s need to understand, to remember, and to share. It is the web developer, playing the part of the 19th-century telegraph clerk, choosing the most meaningful words under severe constraint, understanding that every character in the address is a cost borne by the person who must read it.
We often think of the URL as a technical specification, a mere pointer. But its history is deeply human, rooted in the same problems of navigation, cost, and clarity that have always existed. The next time you design a site’s structure, consider the telegraph clerk. Ask not what the server can parse, but what the user can truly understand. The best address is not just the one that works, but the one that is worthy of being remembered.
Notes & further reading
A few pages I came back to while writing this: