Being Exemplary

I have a riddle for you: which website is one of the most popular on the Internet, but no one needs to visit it?

The answer is example.com.

The Internet Assigned Numbers Authority (IANA) has reserved a number of domains for use in documentation whenever an illustrative example is needed. Besides example.com, there are example.net and example.org, and we also operate example.edu for a similar purpose. As we recently made some changes to the website at these addresses, it is a good moment to learn more about what they are for and why the way we operate them matters.

If you need a domain name in a manual, configuration file, textbook, presentation, or other piece of documentation, you can use one of these domains instead of inventing a plausible-looking domain that may point readers at something in the real world. Consider them the Internet’s equivalent of “John Doe” or “Max Mustermann”.

As a courtesy, we also operate a small website on these domains that performs one basic function: to explain why the domains exist. Over the years, its message has been consistent: feel free to use these domains in examples, but avoid building anything that depends on the website itself.

An accidental dependency

That distinction has become increasingly important as traffic has grown exponentially in recent years. One week in September 2026, the service received roughly 50 billion requests. That is over 80,000 requests a second, and this shows no sign of abating.

Some incidental traffic has always been inevitable given the domains’ purpose. If someone publishes an example configuration containing example.com, some readers will no doubt run it before replacing all the placeholder values.

It is clear, though, that the example domains have gradually become a general-purpose destination that software contacts to do all kinds of things on the Internet. We know of software that uses them to check whether an Internet connection is working. They have been used in systems that automatically test software before it is released. They are used in college courses to demonstrate how the web works. They have been used to trigger “captive portals” that allow you to sign in to hotel and in-flight Wi-Fi networks. There are undoubtedly many other uses we never see directly. It is reasonable to suspect that automated systems, including AI agents that browse the web and write code on someone’s behalf, are contributing to this activity.

None of these uses are what the domains were reserved for.

The problem is not necessarily that they may fail. Indeed, in many cases they probably work perfectly well. The problem is that every time they work, they risk turning this courtesy service into an accidental dependency the whole world ends up relying upon. In this way, it can become critical infrastructure without anyone explicitly deciding it should, one convenient shortcut at a time.

The example.com website is not intended to be a general-purpose Internet utility. We cannot make it all things to all people, and it is not desirable for so much software to rely on a single website to function correctly.

Every byte counts

Over the years, people have asked us to make the page a model of how a good website should be constructed. Others have come to rely on particular technical quirks of how it is set up to demonstrate some specific behavior of the web.

Those requests can pull in the opposite direction from one of our biggest operational concerns: keeping the page small so we can serve it efficiently. When a page is requested tens of billions of times, even a very small increase in its size represents a meaningful amount of additional Internet traffic. For years, we have therefore made small adjustments intended to reduce the amount of data transferred while preserving the page’s usefulness.

We have kept the visible text economical. We have removed unnecessary HTML. We have added technical instructions, like headers, intended to discourage follow-up requests where appropriate. We have looked for opportunities to eliminate pieces without diminishing the basic purpose of the page.

Each change involves a tradeoff. Are we removing something useful? Is a new feature worth the additional cost of delivering it billions of times? Will adding a few bytes in one place actually save more traffic elsewhere?

Trying something new

There is a limit to how much we can optimize against this unyielding growth. As traffic has grown, the bandwidth required to provide the service has become increasingly significant. We are therefore very grateful that Cloudflare volunteered to support the service through Project Galileo, its program that supports public-interest websites. This helps us continue to meet the demand.

This has also allowed us to try something we have not done in a while: adding functionality.

To broaden awareness of the purpose of the domains, the key message published on the website is now available in the six U.N. languages of Arabic, Chinese, English, French, Russian, and Spanish. At the same time, we have changed how the page itself is delivered. Until our latest update, it was a single, small, self-contained file. We are now experimenting with splitting it in two: a small initial page, and a separate file (written in JavaScript) that holds most of the explanatory content.

The reasoning is that most requests appear to come from automated software that only checks if the page is there, rather than from people reading it. That software will receive a smaller response, while a person using an ordinary web browser will see the full explanation. Software that relied on the exact content of the old page may notice a difference, but that is exactly the kind of dependency we seek to discourage.

We are going to monitor this and continue to adapt based on what we see. For each change we make, we consider its effect where it matters the most: the total amount of data transferred. It is not simply a question of counting characters in a source file. Data is compressed before it travels over the network, using algorithms like gzip and Brotli, and different kinds of content compress differently. A change that makes the underlying page larger may cost almost nothing, while another seemingly small change can be surprisingly expensive when repeated billions of times. It is always a considered tradeoff. Saving bytes is never the only goal; we weigh it against functionality, compatibility and clarity.

What comes next

There are no doubt more challenges ahead. One issue that is top of mind is unencrypted access. We have historically made the page available both unencrypted (addresses beginning with http://, delivered over port 80) and encrypted (https://, over port 443). As the web increasingly assumes secure connections by default, preserving both forms may become more difficult for us over time.

Yet this is another example of the unusual position these domains occupy. Something that might be trivial to change on an ordinary website can have unexpected consequences when countless pieces of software have made assumptions about how the service behaves, and we have little visibility into what those effects may be.

This ultimately makes operating example.com interesting despite the fact that the domains are intrinsically boring. They exist so that authors, developers, teachers and standards writers have something safe and predictable to use when they need an example.

Keeping this website online is an evolving challenge, and we will keep refining it so it stays useful and efficient. In the meantime, the example domains are there for you to use in your documentation, configuration examples and prose. They are a safe way to make your point without accidentally involving someone else’s domain.

Just please, if you can avoid it, don’t add another stream to the fire hose of traffic coming our way.

* * *