On Browser TruthThe browser is the source of truth for the frontend · a passing build is only the ticket in

One user reported, “I’m clearly logged in, but the page is asking me to log in again.” I opened the same page locally, and everything worked.

That day’s build was green. The type checker showed no errors, the preflight script passed, bundling succeeded, and the console was clean. By those signals, the frontend was fine. Yet it was wrong for the user. I kept following the issue and eventually found that the avatar read from one state source while the dropdown menu read from another. In the user’s browser, the two sources were out of sync: one showed a logged-in user, the other a guest. I couldn’t reproduce it locally because my local cookies happened to be clean.

After that, I accepted one firm rule: the truth about a frontend is ultimately established only in the user’s browser. Everything else is indirect evidence.

A passing build is only the ticket in

A build has real value, but it proves only one thing: this code can be bundled into an artifact.

It does not prove that the artifact will be deployed correctly, or that the user will receive it rather than an old cached copy. It does not prove that the browser and the server agree on the login state, that the styles won’t obscure text at the user’s actual viewport width, or that some asynchronous state won’t be overwritten by an old value after hydration.

This may sound like picking at details. But a frontend is made up of all these details. Its runtime is not a clean function. It is a scene where a whole set of conditions come together:

Code version
Build artifact
Intervening proxy and access-control layers
Cookies / login state / local storage
Browser cache
Viewport width / pixel ratio / whether fonts have finished loading
Shape of the API response data
Which page the user is on right now, and how far they have scrolled

The build covers only that small stretch at the beginning. It is the ticket in, not the stub you keep after watching the performance.

System boundaries show up in a real browser

I came to rely more and more on a real browser for verification because it brings a whole set of boundaries, usually hidden by abstractions, back into view at once.

It carries the user’s actual cookies, follows the actual routes, and exposes the order in which hydration happens. It brings font loading, scrolling, hovering, mobile breakpoints, caching, cross-origin behavior, and intermediate proxies back into the picture. You cannot see these things in the source code. There, they are either a line of configuration or absent altogether.

Many bugs don’t look like bugs in the code at all. One component reads user information; another reads page-level state. Each piece makes sense on its own, and a review turns up nothing wrong. Only in the browser do you see it: the avatar suggests you are logged in, while the menu suggests you are not. This is not a styling problem. It is two state sources telling different stories in front of the user.

The browser is unforgiving, but fair. It does not care that your proposal document says “fixed,” or how clean the build logs are. It only shows what this user will see at this moment.

A contradictory UI is the most valuable signal

In frontend verification, the most valuable signal is often a contradiction rather than a blank screen.

A blank screen is serious, of course, but it is easy to locate the cause: a bad import, a runtime exception, a failed API, a resource that did not load. A few checks can narrow it down. A contradictory interface is more valuable because it tells you that different parts of the system each have only part of the truth:

• The avatar appears at the top, but the main content asks you to log in;
• One page has data, but another looks as though a guest is viewing it;
• The button is clickable, but the request goes out without authentication credentials;
• It works locally and fails in the deployed environment, yet the build artifacts have exactly the same fingerprint.

These contradictions are not noise. They are readings returned by a probe. They tell you that the system’s truth has split in two at some boundary. It could be the cookie scope, the boundary between server-side rendering and client hydration, a cache layer, a proxy layer, or a configuration value that differs between the deployed environment and the local one.

I stopped rushing to “get the interface right first.” Instead, I began by asking: which two sources of truth does this contradiction show to be out of sync? Only after finding those two sources does it make sense to decide which line to fix. Without that, a change often just covers up the contradiction.

A verification path from the code to the user’s eyes

When I verify a frontend issue now, I make a habit of following four steps, in this order.

First, read the code itself. Read through the components, state, routes, and API calls involved. Work out exactly how many state sources there are, who writes to them, and who reads from them. This step guards against one particular mistake: seeing a field or structure with the same name somewhere and assuming it is the one involved, when it is actually used by a different path. Trace backward from the page the user actually clicked: which API does it call, and where is that API’s response assembled? Don’t guess from a name.

Second, run the type checks and the build. This can show that syntax, types, and bundling did not fail right then. That is all. Don’t let it answer other questions for you.

Third, actually open that page in a local browser. Use a real login session, or explicitly clear the login state, and see what the user will actually see. Check the console, whether network requests carry credentials, whether that node is actually in the page, and what that line of text on the screen actually says. This is where the whole exercise moves from “I think” to “I see.”

Fourth, if the problem occurs only in the deployed environment, access the application from inside that environment instead of merely probing its public endpoint. A responding public endpoint often proves only that the access-control layer in front is alive. It does not prove that the application itself is working correctly. These two things are often treated as one, and the investigation continues from a mistaken conclusion.

You can move through these four steps quickly, but you cannot skip the crucial one, especially the third.

The browser is a probe, not a display window

What really changed my thinking was that I stopped treating the browser as a “display window” and started treating it as a probe.

“Display window” has a passive feel: the work is done, so open it and see how it looks. A “probe” is different: I push it into the system and let it tell me where the layers have fallen out of sync.

When it is a probe, I look beyond whether things look good. I check whether the node that should be there is actually in the page, whether the request carries credentials, whether an old value is still sitting in local storage, whether the console has hydration warnings, and whether that line of text has been squeezed out of view at a particular viewport width.

This is also why a real browser matters more than a screenshot, why a screenshot is more reliable than “I remember it being fine,” and why actually inspecting the page structure is worth more than “it should be okay.” Frontend verification is not an exercise in aesthetics. It is an on-site investigation: you are looking for two sources of truth that disagree, rather than something that looks good.

A frontend that works only in build logs has yet to reach the user

Read alongside the piece about evidence chains for proposals and the one about recurring tasks, this article is another view of the same thing.

The truth about a proposal is not in the proposal document, but in the chain of evidence showing it can be put into practice. The truth about a recurring task is not in its “fallback” label, but in its write permissions and safety boundaries. The truth about a frontend is not in the build logs, but in the runtime of the user’s browser. I increasingly think the key to engineering judgment is knowing where each kind of truth lives, rather than reaching conclusions faster. Look in the wrong place, and all the evidence you gather belongs somewhere else.

The browser is where frontend truth lives. It is indeed noisy and messy, with caches, old cookies left by the previous user, proxy layers, and unpredictable font-loading timing. But precisely because all these things are there, it comes close to the real world.

A frontend that works only in build logs has not yet reached any user. Only when someone has actually opened it in a browser, clicked through it, scrolled, and inspected its structure does it begin to become real. Think back to the user at the beginning who was “logged in but being asked to log in again.” That bug did not look like a bug in any line of code. It showed itself only in that user’s browser. If I had kept staring at the green build, I would never have found it.

Translation log: translated from the Chinese original by Codex on 2026-11-03, 17:48–17:51 (US Eastern). Main thread GPT-6 Astra (gpt-6-astra), reasoning effort ultra; it spawned 1 sub-thread: 1 on GPT-6 Astra (effort ultra). Together they read 366,140 tokens (340,096 of them from cache) and wrote 6,426 (1,030 of them reasoning).