The many URI schemas used by the browsers’ “Reader Views”

Safari was the first mainstream browser to include a built‐in reader view five years ago. Over the last two months both Firefox and Edge have released their own reading view experiences, and Chrome is experimenting with their own version.

The same cross‐browser concept ended up having four different URI protocols and schemas, and behaviors in all the major browsers. Here is a quick overview over the the URI schemas used to render pages in reading view from the big browser vendors:

Microsoft Edge 12’s Reading View

read:http://example.com/

URI is properly registered and can be called from anywhere in the operating system. The URI is stored in the browser session data, so pages reopen in reading view when resuming a session.

Pages added to the Reading List open in standard view or Reading View dependent on what view they were opened in when added to the list.

Links opened from inside the Reading View normally doesn’t send a Referer header when following links. However, links opened by right clicking on a link and opened from that context menu will send the page’s URL prefixed by the “read:” protocol schemas. This can cause issue for logparsers and analytics software who don’t handle unusual protocols very well.

Windows 10 and Windows 10 Mobile versions behave the same way.

Mozilla Firefox 39’s Reader View

about:reader?url=http%3A%2F%2Fexample.com%2F

URI is callable from inside Firefox and by websites and add‐ons. It’s not registered in the system and can’t be used from other programs. The URI is stored in the browser session data, so pages reopen in reading view when resuming a session.

Pages added to the Reading List always open in standard view regardless of whether they were added from Reader View or standard view.

Links opened from inside the Reader View don’t send any Referer headers.

Android and computer versions behave the same way.

Safari 9’s Reader View

safari-reader:example.com/

URI is only used internally in Safari and is not callable even from inside Safari. It’s not registered in the system and never exposed to the user. Safari is unique in not preserving the original URL. The URI is not stored in the browser session data and pages always reopen in standard mode when resuming a session.

Pages added to the Reading List open in standard view or Reading View dependent on what view they were opened in when added to the list.

Links opened from inside the Reader View don’t send any Referer headers.

iOS mobile and Mac versions behave the same way.

Google Chrome 44’s Page Distiller

Google — a giant in the advertisement industry — has a huge conflict of interest when it come to allowing their users to hide their own advertisement. Never the less, they have an experimental reader mode called “page distiller” available in Chrome 44.

chrome-distiller://uuid/?url=http%3A%2F%2Fexample.com%2F

URI is callable from inside Chrome and by websites and add‐ons. It’s not registered in the system. The URI is stored in the browser session data, so pages reopen in page distiller mode when resuming a session.

Links opened from inside the Page Distiller don’t send any Referer headers.

The UUID’s purpose is unknown but you can supplement any string and still have it work.

Chrome doesn’t have a Reading List, but pages opened in the page distiller mode can be bookmarked and resume in distilled mode when reopened.

Android and computer versions behave the same way.


We can only wonder how they all ended up with different URI protocols and why there is so little apparent cooperation between the browser vendors. Unless the browsers are forced to cooperate, they seem to always go their separate ways to differentiate at the expense of interoperability.

Out of the current generation of browser reader modes, I think I’ll crown Microsoft Edge as the best implementation. It’s reader mode is the most accessible to third‐party integration and it has the neatest and simplest URI schema of the lot. Good work, Microsoft Edge team!

“Referer” was intentionally misspelled throughout this article as it refer to a technical header name that originally slipped in to the HTTP Specification.