What emulation actually changes
Device emulation is a narrow, well-specified feature. When a framework applies a device descriptor it overrides the User-Agent string, resizes the viewport, sets a device pixel ratio, marks the context as touch-capable, and sometimes sets a device scale factor and orientation. That is close to the whole list, and it is enough for its intended purpose - checking that a responsive layout renders correctly at phone dimensions.
Everything else continues to describe the host machine. The GPU is still whatever card is in the server. The installed fonts are still the desktop set. The speech synthesis voices are still the desktop OS roster. The math library rounding still reports the desktop operating system, as does the hyphenation dictionary and the system colour palette. The codec matrix still reflects the desktop build. None of these are touched, because none of them affect layout.
The result is a device claim with essentially no supporting evidence. A phone User-Agent is a statement about a category of hardware, and that category implies a mobile GPU, a mobile codec profile, a mobile font set, motion sensors, and a specific set of platform APIs. Emulation supplies the string and none of the implications.
The checks that separate a phone from a phone-shaped viewport
| Signal | Real phone | Emulated desktop |
|---|---|---|
| WebGL renderer | Mobile GPU family | Desktop or server GPU, or a software rasteriser |
| Motion and orientation events | Fire continuously from real sensors | Never fire, or the APIs are absent |
| Pointer and hover media features | coarse pointer, no hover | Often still reports a fine pointer with hover |
| Desktop-only APIs | Absent | Keyboard layout and similar desktop APIs remain present |
| Speech voices | Mobile OS roster | Desktop OS roster |
| Fonts and text metrics | Mobile system font set | Desktop font set |
| Screen vs viewport | Consistent with a real device and its browser chrome | Viewport resized while screen may still describe the host display |
The GPU check is usually decisive on its own, because the renderer string names hardware directly and no phone contains a desktop graphics card. Sensors are a close second: a real handheld device produces a continuous stream of motion readings simply from being held, and their complete absence under a mobile identity is difficult to explain. Beyond individual signals, the pattern is a straightforward cross-API coherence problem - the claim and the capabilities describe two different devices.
When a mobile identity is worth the trouble
The honest answer for most public-data collection is that it usually is not. Emulation exists to test layout, and it does that well. Using it as an identity means committing to back a hardware claim with hardware evidence across the GPU, sensors, fonts, codecs, voices, and platform API surface - and every one of those is set at a layer below the emulation feature.
Where a mobile view genuinely returns different data than the desktop view, the alternatives are usually better. Many sites serve the same content to both and differ only in layout, so the desktop path is equivalent and carries none of this risk. Where a site really does serve a distinct mobile experience, running on genuine mobile hardware or a mobile-class environment supplies the evidence that emulation cannot.
The general principle is the one that runs through the whole coherence family: make the claim true rather than defending an untrue one. A managed web data API that offers real device profiles solves this by having the underlying environment match the identity, so the supporting signals agree without a compatibility matrix to maintain.