Example.com just launched the biggest redesign in decades
debugbear.com
debugbear.com
Also open-source and self-hostable: https://github.com/httptoolkit/testserver. Lots of other endpoints too, full docs here: https://testserver.host/
As an example, depending on "man -w" not outputting anything to stderr: https://unix.stackexchange.com/questions/405783/why-does-man...
We removed the version and a few customers complained we broke their stuff.
Our back clapping was interrupted by an angry customer phone call. One of our customers had gotten access to our internal schema and had a massive reporting setup in Access solving most of his needs.
I ended up converting his reports using some internal tools we had. Customers will grab anything to give them.
[The caliber and depth of his reports were such I wish we would have bought them instead of making me spend months building out our own reports.]
Learning from customers is some of the best learning you can do. :)
This is probably an even more important principle in the age of LLMs.
That's an interesting case. Did you consider this a correct result?
On one hand, <foo@example.com> is a valid hypothetical address that can be used strictly in documentation. It is also syntactically valid, which is the best kind of valid. However, <foo@example.com> (and all its permutations) is an obviously invalid actual address if you're trying to send email to it, or manipulate it in any real way on the Internet.
It's a good sanity check, but quite pedantic. I can understand if you are validating some public input form, where people are likely to put fake email addresses, and you don't want someone knowingly filling in <blah@example.com> because you also know, a priori it's a fake, and it will waste your time validating or trying to send to it.
/s
The web page at example.com is maintained as a courtesy by IANA in order to explain the purpose of the example.com domain to wayward humans.
In the nomenclature of RFC 2119, one MUST NOT design computer systems that rely on the correct operation of an HTTP server at that domain. [0] Plus, it's _really_ rude to pound on a small-scale service being provided as a courtesy... go hit the home page of a tech megacorp (such as Microsoft or Google) or the status page for a major CDN (such as Cloudflare or Akamai) instead!
[0] I expect that someone here will want to pop up with a "gotcha" where they say something like "Oh, but IANA's email says that automated use is strongly recommended against, rather than prohibited and besides, they can't actually stop me from doing it!". To that, I reply "Sure, and standards-writers can't actually stop implementers that do the profoundly antisocial thing and do the things they MUST NOT. As any adult who's been paying attention to the world around them throughout their lives knows, there's only so much you can do to stop people who are very determined to be enormous assholes.".
Would you settle for any old static page served by Cloudflare? For instance, example.com? https://bgp.tools/dns/example.com
In the nomenclature of RFC 2119, one MUST NOT design computer systems that rely on the correct operation of an HTTP server at [example.com.] Plus, it's *_really_* rude to pound on a small-scale service being provided as a courtesy.Maybe Cloudflare gives them a good rate, or is donating service, but it's also possible or even likely that IANA is just using Cloudflare as a vendor, and therefore is paying for all the traffic, which is why they don't want people relying on it or hammering it all the time
Much too big for metered data, full of ads, and importantly they all mandate HTTPS these days, which breaks my use case of forcing a captive portal on paid/login-gated Wi-Fi to render.
example.com is (unfortunately for the IATA) the almost perfect "can I reach the Internet" service: It's unlikely to go away, supports HTTP, is fairly small, easy to remember, and I don't care if a captive portal poisons my DNS cache with a fake response temporarily.
You'll be pleased to learn that nearly (actually?) all major sites that mandate HTTPS provide an HTTP redirect response when hit on port 80. You can't help but agree that a 30X with no body is way less data than pulling down even just the HTML parts of example.com.
curl -v http://cloudflarestatus.com
* Trying [2600:1901:0:4a3b::]:80...
* Host cloudflarestatus.com:80 was resolved.
* IPv6: 2600:1901:0:4a3b::
* IPv4: 35.201.124.30
* Established connection to cloudflarestatus.com (2600:1901:0:4a3b:: port 80) from [REDACTED] port [REDACTED]
* using HTTP/1.x
> GET / HTTP/1.1
> Host: cloudflarestatus.com
> User-Agent: curl/8.22.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 301 Moved Permanently
< Cache-Control: private
< Location: https://www.cloudflarestatus.com:443/
< Content-Length: 0
< Date: Wed, 07 Oct 2026 08:07:34 GMT
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host cloudflarestatus.com:80 left intact
> ...which breaks my use case of forcing a captive portal on paid/login-gated Wi-Fi to render.
Huh? Captive portals -especially ones that redirect to payment collection systems- are served up by infrastructure that either you control or that you've arranged with someone else to operate. If you're paying IANA to operate your captive portal, and they've made the choice to hit example.com:443, then that's their -odd- choice... but I bet that's not who's operating your captive portal.
If you've designed a captive portal system that depends on a functioning HTTPS server at example.com, you desperately need to go back and redesign it... if for no other reason than to -given your concern about metered data- massively reduce your own bandwidth bills.
> This is not a service; avoid relying on it for testing and monitoring purposes.
So yeah I would pick something simpler for a network access test probably?
It's a static page that every Apple device relies on saying only:
<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML> ~$ ping -c1 1.1
PING 1.1 (1.0.0.1) 56(84) bytes of data.
64 bytes from 1.0.0.1: icmp_seq=1 ttl=56 time=7.89 ms
--- 1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.888/7.888/7.888/0.000 msIt's a shame that we don't have any standards for the concerns of canonically testing Internet reachability and for authoritatively redirecting network users to a captive payment portal (without having to resort to ugly hacks that often break with TLS).
But even just having an RFC to yell about is great, thank you :)
I caught it in review but thousands of others won't.
That ship has sailed I would say.
I've seen google STUN servers used in production. Folks probably rely on unpkg too much to deliver their JS. Good to consider these failure modes.
If your service runs on AWS, reaching amazon dot com seems somewhat more reasonable an internal health check.
Also as a _long_ list of other specialist TLS endpoint configurations if you're interested, which can be arbitrarily combined, see https://testserver.host/#tls-endpoints.
That gives neat tricks like https://tls-v1-2--expired--incomplete-chain--http2.testserve...: only accepts TLS 1.2, then sends an expired certificate but fails to send the intermediate cert for the chain (so the client must infer it) and then negotiates HTTP/2 for the connection on top. Fun!
If you want to hit it hard, or you just want to avoid any risk of limits in future, it's a one-liner to host it yourself with Docker: `docker run --rm -it -p 3000:3000 httptoolkit/testserver`, then open http://example.localhost:3000/. Advanced config options for CAs etc are in the GitHub README.
Yes, I know it's not the example.com's fault, and it's a side effect of Hyrum's Law:
> This is not a service, avoid relying on it for testing and monitoring purposes.
Don't we all have a few fragile tests?
Pinging such an address is inherently a troublesome practice. This address, like many public DNS servers (resolvers as well as root and authoritative ones), uses "anycast" routing methodology.
https://en.wikipedia.org/wiki/Anycast
Pinging an anycast address will yield a cornucopia of different results. Of course, people who naïvely "ping" a recognizable or easy-to-type IPv4 address get what they deserve, especially when they enshrine it into software, unit tests, or the LLM coughs up such tokens on their behalf.
Fundamentally, the question is "what do you really want to test?" by pinging a particular IPv4? Do you want to test Layer 3 connectivity? Test your ISP's backbone and connectivity? Test only your upstream router? Test the existence of ICMP in your stack and theirs?
... the possibilities are endless. Your router can do anything. Ping zombo.com.
Pinging a domain name could fail for a variety of other reasons, particularly if it's not a reliable site. Cloudflare's business is being reliable; few sites would be a better choice.
But it’s a good “is traffic making it past my router with some semblance of connectivity” sanity check, and easier than finding the provider-side next hop address.
[0]: https://stackoverflow.com/questions/1672338/how-to-sleep-for...
The thread you linked to suggests 'timeout'[0]
[0] https://learn.microsoft.com/en-us/windows-server/administrat...
Look what happened because of what you did, what it led to! Two microservices are in critical condition and you're laughing. You're laughing.
I don't think people are using `ping 1.1.1.1` as a stable API, rather as a yes/no test of the network segment that they control.
Likely for good reason, even back then there would have bound to be lots of misconfigured endpoints trying to access 1.1.1.1, so just blocking it at the earliest point possible kept at lot of the annoyance away. Nowadays, it’s an anycast address, so it’s slightly less bad.
But for me, old habits die hard.
Just before COVID, a random unidentifiable person reported that 1.1.1.1 saw 60Mb/s of ICMP echo traffic. When APNIC first experimented with making it a valid network almost a decade before that, it was being sent 50Mb/s of general IP traffic. Amusingly, a side-effect of what CloudFlare has done is that it has stopped all of that traffic leaving the edges of the Internet, and funnelling in to one big central place.
There are those who remember the risks of 'just use 1.1.1.1' and how the people who did that used be characterized as 'bad Internet citizens'. The ServerFault answer (q.v.) is from 2011.
* https://labs.ripe.net/author/franz/pollution-in-18/
I went and checked and in fact it is already serving a script s.js so I guess you’re right!
Looks like they removed this and instead just show all languages with no CSS animation now.
It still probably is as it is now. But there's better arguments to support localization than transitions.
Well, no. The purpose of the redesign is to move as much of the page content as possible into an external javascript file. There's no question of what parts of the page require javascript; the question is what parts of the page can be moved into javascript.
IANA's email about why example.com changed - https://news.ycombinator.com/item?id=49915060 - Sept 2026 (20 comments)
McCarthy of DebugBear clearly noticed this admonition and perhaps the mistake as well, because they have carefully highlighted "example.com" without linking to it, although they apparently have visited the site in order to copy and cite screenshots and unpack the CSS, and describe an extensive history of it.
(I actually tried the select, share [sic], open in browser route, but for some reason I only saw opera as an option, not chrome, the browser I actually use for everything. Links still rule.)
I am devastated.
I kinda expected this to be Ford Model T "Any color the customer wants, as long as it’s black" joke.
data:text/html,<body%20bgcolor="white">I guess this is also done to prevent bad actors from abusing the fact that this domain is hit by people who might not know what they're doing (the ones copy-pasting code without reading it)
> Someone else could
When you own a domain, you can choose not to serve anything on HTTP/S, and still nobody can come and serve some other website on your domain, because they don’t control the DNS records.
I remember getting my start with web development by simply reading the source code of sites I found interesting and trying to recreate them. example.com isn't exactly very interesting but it feels like compressing the HTML isn't in the spirit of things either.
On a side note I'd love to see how complicated (or maybe simple) the hosting setup for this site actually is behind the scenes.
But beyond that, what are you referring to as compression? When I look at the source I see a VERY short easily human-readable HTML page. It doesn't have newlines, but I wouldn't consider that compression. It also references a short, but non-obfuscated javascript file at https://example.com/s.js .
Maybe I misunderstood what you're referring to...
separate shower thought: Microsoft have used contoso.com as the example domain in their docs for 25+ years. I bet the logs for that domain are absolutely wild.
> Looking at the visual timeline, we can see that changes to example.com happen sporadically.
I am glad to see someone else struggling to write a non-awkward conclusion to a technical blog. I always feel like I am just restating the obvious to the point that it is borderline insulting to the reader. But I don't have much more to say and removing the conclusion makes it seem like the whole thing just fell off a cliff.
Ultimately, the example.com domain is just there so you can use it in documentation or code examples. Your expectation about the actual example.com domain should basically be none at all, maybe with the exception that it's hopefully not doing actively malicious things like serving malware or running a catchall mailbox feeding spammers.
Whatever HTML they server or if they serve anything at all... shouldn't matter.
which does appear to say that yes, IANA hosts this
Given that they have gotten spiked by automated requests lately, aka agents, wouldn't this at least be respected by the big players?
Also, as they are using Cloudflare, wouldn't a discussion (or a note from IANA or CF) about how they configured CF request rejection and how one should love CF's flat rate static serving be appropriate?
Am I missing something?
Wait - using JS for dynamic content is understandable, but why using it for inserting a static SVG?
The whole article reads like something put together with AI, so maybe it’s not too surprising.
0
```
var B = document.body, P, p; B.children[0].insertAdjacentHTML("afterend", "<p lang=ar dir=rtl>هذا النطاق مُخصص للاستخدام في أمثلة التوثيق دون الحاجة إلى إذن. هذه ليست خدمة، يُرجى تجنب الاعتماد عليها لأغراض الاختبار والمراقبة.</p><p lang=zh>该域名仅用于文档示例，无需获得许可。这并非一项服务，请勿将其用于测试和监控目的。</p><p lang=fr>L’usage de ce domaine est réservé à des exemples de documentation, sans autorisation préalable. Il ne s’agit pas d’un service ; son utilisation à des fins de test ou de surveillance est à éviter.</p><p lang=ru>Данный домен предназначен для использования в примерах документации без необходимости получения предварительного разрешения. Это не сервис; не рекомендуется его использование для тестирования и мониторинга.</p><p lang=es>Este dominio está destinado al uso en ejemplos de documentación sin necesidad de permiso. Esto no es un servicio; evitar utilizarlo para realizar pruebas o monitoreos.</p><a href=https://iana.org/help/example-domains>Learn more</a>"); P = [...B.querySelectorAll("p")]; P[0].lang = "en"; navigator.languages.some(l => p = P.find(p => p.lang == l.split("-")[0])); p = p || P[0]; B.prepend(p); B.insertAdjacentHTML("afterbegin", '<style>svg{display:block;margin:-2.75em auto 0;opacity:.55}p+p{font-size:.875em;opacity:.6}</style><svg viewBox=0,0,20,20 width=44 height=44 fill=currentColor aria-hidden=true><path fill=none stroke=currentColor stroke-width=1.3 stroke-linejoin=round d="M6 4H3v12q4 0 7 1.5-1-3.5-4-4.5V2q3.5 1 4 3v12.5q3-1.5 7-1.5V4q-4.5 0-7 1"/><g transform=rotate(-6,13.6,8.3)><path id=q d="M11.5 6.6h1.8v1.8l-1 1.6-.6-.3.8-1.3h-1z"/><use href=#q x=2.4 /></g></svg>')
```
1
```
<!doctype html> <html lang=en> <head> <meta charset=utf-8> <link rel=icon href=data:,> <meta name=viewport content="width=device-width,initial-scale=1"> <title>Example Domain</title> <style> html { color-scheme: light dark; background: light-dark(#eee,#222) }
body {
font: 16px/1.6 system-ui,sans-serif;
max-width: 26em;
margin: auto;
padding: 25vh 2em 2em;
text-align: center
}
</style>
</head>
<body>
<p>This domain is for use in documentation examples without needing permission. This is not a service; avoid relying on it for testing and monitoring purposes.</p>
<script src=/s.js></script>
</body>```
Regardless, it’s a lot of code, so maybe better move it out to a pastebin/gist?
>pointless SVG image
It's good to have a little color/flavor/spice in life.
Good for them, and it's still better than nothing. Without it the page would almost looked broken it's so bare.
Well, IATA – give me api.example.com or sniff my user agent and I'll be out of your hair :)
(This was when it had the language scroll though, I think moving the extras to JS should have resolved that issue; maybe I was misremembering the details too.)
example.com is not a user-facing service. I don't want to disparage the designer, but it's not meant to be pretty. It's meant to be small so you can copy its response to an automated test or visually verify its correctness, or just out of the bandwidth consideration you'd still be serving it to billions of requestors, even if you insist it's not meant to be used that way.
example.com is meant to be legally allowed to be used in text such as "You visit a website (example.com) to browse the internet"
It is not meant to be queried by automated tests or used as a service.
It is not, in fact, _meant_ to be used that way.
It's 4.5x the size of the original. Which sounds bad, until you notice this means it's 2540 bytes and serves the explanatory text in 6x the number of languages. And it's now served with brotli compression, for a total of 1713 bytes. Or 334 bytes if you only request the HTML (which still has a usable page with the full English version of the explanatory text), like a basic scraper or a health check would. So for the vast majority of traffic, it's now half the size of the old version.
I notice it's been through several revisions, the pre-2025 version of the site most people are familiar with is 1270 bytes because it didn't make use of any minification, and it also triggered an unnecessary `/favicon.ico` request because it didn't use the trick to cancel the request.
eg If they put DNS, NTP etc on it... Likely billions per hour or something equally ludicrous.
Deluge is likely an exponential understatement.
Apple operates http://captive.apple.com, which returns `<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>`.
Microsoft operates http://www.msftconnecttest.com/connecttest.txt, which returns `Microsoft Connect Test`.
Mozilla operates http://detectportal.firefox.com, which returns `success`.
These are what these companies' respective browsers/operating systems use to check if they have an internet connection and are not stuck behind a captive portal. Given the enormous quantity of devices out in the world that are relying on these URLs to stay up, you can probably feel comfortable using these in your tests. If they do go down, good chance you'll see news articles about it before you notice your tests failing.
It cannot manage a one page website. WTF
There are no page "aseets", no need for images, CSS, etc. It was a text-only website to test connectivity
iana.org forwards to Cloudflare, too
Fortunately the FTP server service still works
Without assistance from a third party
If it's been a sensible decision to use Cloudflare for some period of time then why did IANA wait until now
(Yes, I know they used Akamai in the past)
Years ago IANA started requiring a user-agent header
FTP access to root.zone remains
It's only responsible for root.zone, root.hints, .arpa and .int zones
AS112 is a volunteer project not a company
It would not occur to me that my examples may lead somewhere at all. I was actually glad they do not, to spontaneously break incorrect configurations.
Isn't there a dedicated site called nohttps or something? NeverSSL? I just tried http NeverSSL, and it redirected me to an https page with a random hostname and an Amazon SSL certificate!
Does example.com still function this way, with http and no HSTS? I noticed that my Chrome browser was immediately redirected in the customary way.
Are you perhaps on an untrusted network which is spoofing that url to make it redirect somewhere else?
If this is a joke, it's over my head. If not, I'm not knowledgeable enough in this space to pass judgement, but that would seem crazy to me. Like the owner should consider a domain name change :)
Kinda weird setup!
Edit: okay, the subdomains also have SSL. I guess the random subdomain thing is to make sure it hasn’t been cached in a “this site has HTTPS” list. The HTTPS is needed, of course, to please the browser makers, as the parent says.
This is very useful, thanks for sharing!
IANA's email about why example.com changed
example.com, example.net, example.org, and example.edu, along with .example, are all classified as the same type of name, reserved for documentation purposes.
Furthermore, there are IPv4 and IPv6 addresses that are reserved for documentation purposes! You never need to write live addresses, or even private RFC 1918 addresses!
When a newbie learning programming sees this message, then this is a downer.
"Hello World from example.com [more info]"
A newbie shouldn't test their programs using example.com
Even though IANA says example.com is intended for documentation purposes and not as a service, I feel that it nonetheless serves as a service to the broader internet. I think there are some cornerstone services on the internet, regardless of the maintainers' intentions or their legal definitions.
For example, we ourselves sometimes have to recognize that we are not a standard API service. Considering that we expect to process 3 trillion requests this year, a major outage could take down a good chunk of IT systems everywhere. So, we invested in infrastructure to avoid outages. We then started adopting other cornerstone services and running them indefinitely because we might as well support the users who depend on them because we have infrastructure to support them and us.
Instead it just seems to be an advert for ipinfo on a post about example.com?
The issue with example.com is this statement:
> This domain is for use in documentation examples without needing permission. This is not a service; avoid relying on it for testing and monitoring purposes.
The problem is that, disclaimer or not, if a website provides a useful utility, people will use it as a service.
If example.com breaks, IANA can reasonably say it was never intended to be stable. But that does not change the fact that people will use it for testing and monitoring.
What we do is adopt legacy services whose maintainers can no longer afford, want, or have the resources to maintain them, and invest in keeping them running reliably.
> As it tends to be heavily trafficked, the overall bandwidth is a key consideration
It’s always funny when I get French YouTube ads. As if YouTube is desperately trying to offload the adbuys anywhere they can by pretending that Canada must mean French.
And get I often get websites and ads in the language of the country my IP points to
(And false often enough that guessing language based on IP address works badly in practice, I hear.)