The Image Layer of app.onepassapps.com: 57 Images, Two Paths, One File

Disclosure first: I work on OnePassApps. This is a measurement of our own site, not of someone else's code.

Every public URL in our sitemap is a page we wrote, so this time I read the HTML the server actually sends - not the page you see once the app boots - and counted what is in the markup. Fifty-six URLs from the sitemap, one fetch each, plain HTTPS, no browser, no session, no cookies and no JavaScript, measured on 8 November 2026.

The image layer is the interesting part. Fifty-seven img elements across those 56 pages, pointing at exactly two files - and those two files are byte for byte the same drawing.

The census

Two source paths, 57 tags, 56 pages. The split is not random: /brand/sam-mark.svg appears on exactly the 33 pages that boot the application bundle, and /favicon.svg on exactly the 23 that do not. That is the same 33 / 23 split we measured when we looked at the script layer, so the image layer follows the JavaScript layer exactly.

Two paths, one file

Both files are 531 bytes. Both are SVG with a viewBox of 0 0 32 32. Both draw the mark with three path elements and no title, no aria-label and no role. And their SHA-256 digests are identical:

e33c8bd18de73ee84acbdcd598e8020c7992016eaac174cb6e004738cb462ab5

One drawing, two names, one file served twice.

We have already published the seven brand files we ship - the favicon, the touch icon, the install icons and the social card - and that census found no duplicates among them. This is the eighth path, and it is a duplicate of one of them: /brand/sam-mark.svg is the same 531 bytes as /favicon.svg.

Where each one sits

The 48-pixel mark lives inside the pre-JavaScript fallback card. Every one of those 33 pages carries a hidden section with data-shell-fallback and role="alert", and the brand mark is the first thing inside it, before the text. The card reads "OnePassApps stopped working in this tab. Files and data saved on this device are unaffected." That is the shell we published on the script layer, and the image at the top of it is the same mark as the favicon.

The 23 guide pages carry no application bundle, so they carry no fallback card. Their brand link is an a element with the class gd-brand pointing at /, and it holds a 32-pixel copy of the same file next to the word "OnePassApps". The guides index carries that 32-pixel copy and one more at 56 pixels.

Both files are also named in the head of every page as the icon: 56 link references to /favicon.svg across 56 of the 56 pages.

What every one of the 57 has in common

• alt="" on all 57 of them. Not one carries descriptive text. On the guide pages that is the standard pattern for a decorative image: the link beside it spells out "OnePassApps", so the link keeps its name.
• Explicit width and height on all 57 of them: 48 by 48 on the fallback marks, 32 by 32 on the guide brand links, and 56 by 56 on the second copy on the guides index. The box is reserved before the file arrives.
• No loading, no decoding, no fetchpriority, no srcset and no sizes on any of them.

The controls, and the links

There is not one form, input, textarea, select or button element in the HTML the server sends on any of the 56 pages. Every control you can use on our site is built by JavaScript after the page loads. The document we serve is text, links and one image.

That leaves 1,058 anchors. 24 of them open in a new tab. Nineteen point off-site and every one of those nineteen carries a rel attribute: 18 say noopener noreferrer, and one - the complaints link on /terms - says noreferrer on its own. The other five new-tab links are internal, and they point at the data files behind the Terms page, which is why they open in a new tab at all. No anchor on the site carries a role attribute.

Limits

One build, one day, 8 November 2026, plain HTTPS from one network, signed out, no browser and no JavaScript, one request per URL. So this is what the server sends before the app code runs, not what a page looks like once it does. The byte counts and digests are a snapshot of one build, and nothing here is a claim about how any browser paints or schedules these images.

The apps themselves are at the app list and the guides are at the app guides.