Note that this article is about a feature that, at the time of writing, has been almost universally disabled or hampered on many platforms. Expect some or all things to not work.
Everyone in tech at one point has joked about serverless websites actually using servers behind the scenes. This isn't that, this is web content you can access with a URL that doesn't require any networking.
Blue boxes are the sources of content in each scheme
I'll call the web as we know it today the "networked" web, because it relies on HTTP and the internet to deliver content to browsers and other user agents. The "local" web I'll be theory-crafting in this article doesn't require networking or HTTP at all, instead embedding content directly into the URL.
The basis of this is based on a web feature that still works on some platforms, below there's a tool for creating your own "local web" URL:
Note that pasting the URL into a mobile browser is unlikely to work. You might have to try on a desktop browser like Firefox, or simply trust that it works and continue onwards.
To use the tool, try making some edits in the text area, click the "Copy URL" button, and pasting it into a new browser tab navigation bar.
You should see whatever web content you wrote appear in your browser. Taking a look in the browser inspector network tab will show no activity.
What is a data URL?
Data URLs
are URLs prefixed with the data: scheme and allow embedding content directly into the URL itself
instead of indicating where a browser should request data from. Data URLs are capable
are encoding any content type, including HTML content (i.e. text/html).
Data URLs are made of 3 components, a mime-type, an optional base64 encoding "flag", and the data value which is either encoded as text or base64-encoded bytes depending on the base64 flag:
data:<mime-type>[,base64];<data>
For example, below is the data URL encoding the data for Hello, world! with the mime type text/plain:
data:text/plain,Hello,%20world!
What would a local web look like?
I love networking as much as the next person and there are obvious benefits, but there are also downsides to serving most websites across networks:
- Websites require a server somewhere and (unless your name is an IP address) likely a domain name. Both of these things cost money to run.
- URLs don't encode the information of the resource, only its potential location. This means resources referenced by URLs can be lost if the server at the other end ceases to exist.
- All web content requires electricity and connectivity for both client and server to work.
- Geographically distant users or users with worse network conditions have degraded performance.
The combination of browsers, HTML, CSS, and JavaScript are an incredible platform for building experiences, it'd be great if we could take advantage of those benefits without any of the downsides listed above. Let's build a local web with data URLs?
Referring to top-level
data:URLs as being part of the "web" is an oxymoron, the web is meant to be an interconnected graph where our data URLs are functionally isolated nodes on that graph.
Sharing URLs
Right away data URLs have an ergonomics problem. Because they encode all the information in the URL itself it's tough to imagine typing one out with the same ease that you'd type out "example.com". If we're assuming that we're completely offline we also can't use a search index like DuckDuckGo or Google.
Luckily there's already a mechanism for getting long URLs into the browser:
QR codes mean we can encode our data URLs into an image that can be scanned with a camera. Unfortunately this would mean that our data URLs are only shareable to devices with cameras (sorry laptops) but given the circumstances of "no internet" I think it's more likely interested users would be using a phone instead of a laptop.
QR code for the data URL of "example.com"
The content uses 1,290 of the maximum 2,953 bytes of information encodable in a binary QR code
You'll notice that the example.com QR code doesn't scan with your camera's built-in QR parser. Encoding a data URL into a QR code isn't against the QR standard (which allows arbitrary data, deferring to scanners for deciding what to do with the data) so this means the parser itself is refusing to process the data URL.
Dynamic content
One of the downsides of data URLs is they're static, whatever resources are embedded in them are there forever. New content requires either JavaScript and an internet connection or to create a new data URL.
This constraint is similar to physical media formats like cartridges, records, and disks. Creators of these physical media formats had to get everything right before they were distributed to users, you can't patch or update the media after!
If we carry on using QR codes as a means of distributing local web content we can use either screens to update QR codes automatically (after considering whether the information can be displayed directly to the screen) or using stickers or labels which are cheap to print if content needs to be updated on a semi-regular basis in a centralized location.
Encodes the above text area as a data URL QR code
Size constraints
Websites can be any size, and frequently are on the order of megabytes (!) in terms of total content size. Data URLs encoded into QR codes can't be any length as they are limited in size in two ways.
The maximum amount of data a QR code can encode depends on multiple variables. QR codes can be different "versions" (i.e. "sizes"), have different error correction formats (L, M, Q, and H), and be a different "type" (Numeric, Alphanumeric, Binary, and Kanji).
Since we need more than alphanumerics to encode base64 data and the : character we'll need to use the "Binary" type.
Optimizing for total amount of data with low error correction and version 40 we can fit a
maximum of 2,953 characters into a QR code.
URLs have no maximum size according to standards, however in practice many browsers will limit URLs to a maximum of 2,000 characters, so to be on the safe side we'll be constrained to 2,000 characters in a data URL.
Base64 generally increases the size of a string by ~1.3x, so dividing 2,000 by ~1.3 we get ~1,538 bytes of data encodable into our data URLs. Quite a bit smaller than multi-megabytes websites of today.
Use-cases for data URLs
So given all of the above constraints, what niche would data URLs fill for real-life usage?
- Small amounts of static data that doesn't need to update frequently
- Users are likely to have mobile phones when encountering the data URL
- Users are unlikely to have network connectivity OR the distributor of information wants to minimize spend/operations by not running a website
- Users may want to access information after opening the data URL
- Provide additional information mixed with information your phone still has access to (think GPS, accelerometer, contacts, pictures)
Using the above constraints I can think of a few cases:
- Maps for remote locations or trails. Phones typically have GPS signal even without internet connectivity. QR codes could be placed at trailhead signs.
- Providing a decent initial web "landing page" for a QR code in areas where internet connectivity is spotty or unavailable so would provide a negative experience after scanning the QR code. For example advertisements on trains, subways, or airplanes. These data URL "landing pages" could automatically upgrade to the real-deal once internet connectivity is restored.
- Restaurant food and beverage menus are frequently encoded into a QR code. This requires serving a PDF or webpage from an actual website so costs money to maintain. Instead restaurant owners could encode their menu into a data URL for a zero-cost solution.
I'm sure there are many more example, send me any interesting ones you think of yourself.
Data URLs are dead, long live data URLs
So what's the biggest barrier to the local web being possible? Data URLs are dead.
Data URLs were essentially blocked from use as top-level domains (and thus in QR codes)
by all major browsers in 2017 citing phishing, being confusing for users, and interacting strange ways with other standards (for example, should a data: URL be considered "secure" or "insecure"?)
According to caniuse.com, the base href can't be data: for 92.75% of global browser users.
This ends our hypothetical local web journey, hope you had fun! 🥲
QR codes generated using the MIT-licensed 'qrcode-svg' project. Copyright (c) 2020 datalog.
Thanks for reading! ♡ Did you find this article helpful and want more content like it?
Get notified of new posts by subscribing to the RSS feed or the email newsletter.
This work is licensed under 
