How browser fingerprinting works on simple pages

Browser fingerprinting lets a website recognise a returning visitor by combining characteristics of the browser, device and connection. Instead of assigning a cookie, the site derives a short identifier from signals such as screen size, language, graphics rendering and supported features. The identifier may be recomputed on each visit or sent with a request, allowing recognition without visible storage on the device.

A sparse page does not need a complex application to create that profile. A small script can gather traits, hash them and transmit the result, while even a page with no script may expose network-level details to the server. This matters for a page containing only a “Click here” link: the destination can connect a click with earlier browsing activity, although a URL parameter and a fingerprint are separate tracking mechanisms.

Signals available before a page loads

Before any pixels appear, the browser sends an HTTP request containing headers that can narrow the visitor’s profile. User-agent strings, accepted languages, operating-system details, compression support and header order may all contribute. At the network level, the source address, connection protocol and TLS characteristics can also distinguish clients. These passive signals require no permission prompt and may be visible to the server merely because the page was requested.

JavaScript adds traits that are harder to observe from the network alone. It can inspect the reported time zone, locale, screen and colour depth, touch capability, device memory and processor concurrency. It may enumerate available fonts, test audio processing, or ask the graphics system for a rendered WebGL signature. The page can run this process in a fraction of a second because many values are already exposed by the browser.

No single trait is reliable. A desktop and phone may share an operating-system family, while thousands of users can run the same browser version. Fingerprinting works because the site combines weak clues into a larger pattern. It also separates durable traits, such as a display configuration, from volatile ones, such as a changed IP address or temporary battery state.

From browser traits to a stable identifier

A typical script normalises values, applies tolerances to noisy measurements and hashes the result into an opaque string. Changing one attribute may produce a different hash, so developers sometimes group close matches or select only stable features. They can then compare that value with earlier observations, store it in local storage, attach it to an analytics event or send it as a custom header.

A link from a sports news page can therefore lead to a site that sees both the navigation event and the traits of the device making it. The new site need not display a cookie banner for those traits to arrive in its server logs or analytics system. The identifier is useful precisely because its collection is largely invisible to someone simply reading the link label.

The output is a statistical profile, not a guaranteed identity. Two people can receive the same value if their configurations match, and a browser update can force re-identification. Shared office computers, family tablets and heavily reduced browser settings also create collisions. Even so, a sufficiently rich set of characteristics can make one visitor stand out among a large pool.

Why small pages remain observable

Browser fingerprinting on a simple page is entirely possible: a destination built as a simple landing page may have plenty of fingerprinting capacity despite offering no articles, forms or shopping features. One inline script can collect the available traits and post them to the same domain. If the site is controlled by an advertising or analytics provider, even a blank-looking page may rely on infrastructure shared with thousands of unrelated destinations.

Canvas and audio tests are common because their output can vary with graphics drivers, fonts and floating-point processing. A script might draw an off-screen image, measure a subtle colour difference, or render a short sound and inspect the resulting samples. Browser privacy features can add random noise, limit font enumeration, standardise hardware details or block some APIs, reducing the identifier’s stability and uniqueness.

Some browsers also partition storage, limit cross-site information and resist scripts that resemble fingerprinting. These measures help, but they do not affect passive server-side observations in the same way. A site can still correlate request headers over time. Consequently, the amount of content on a page is a poor guide to how identifiable its visitors may be.

Links, redirects and cross-site signals

A redirect containing a tracking-style query parameter can record a click through the URL and the receiving server’s logs. A browser fingerprint serves another purpose: it can connect that click to a device seen elsewhere. The same redirect may therefore carry two pieces of information, one visible in the address bar and one derived invisibly from the visitor’s environment.

Shared third-party scripts provide a second correlation path. If several simple pages load code from the same advertising host, that host can receive a consistent identifier from each site. A link labelled lottery betting guide can also act as a navigation bridge, passing context through redirects, while modern referrer rules determine how much of the originating address is disclosed.

Neither mechanism means the destination automatically knows a person’s legal name, and fingerprinting should not be confused with authenticated identity. It can still support profiling, ad targeting, fraud controls and audience measurement. The privacy question is whether a reasonable Australian visitor could understand the data flow, exercise meaningful choice and object to a use that has no justified purpose.

Signals particular to Australian visitors

Australian visitors add regional traits that scripts may notice. A laptop set to Sydney often reports the Australia/Sydney time zone, while a device set to Melbourne uses Australia/Melbourne; daylight-saving changes can distinguish the state more precisely. English is commonly requested as en-AU, and regional settings may produce Australian date formats, currency displays and keyboard layouts. These values narrow the pool further.

Everyday connectivity makes the signals mixed rather than simple. A commuter may move from a train’s mobile network to a café’s public Wi-Fi and then a home connection in Brisbane, changing the IP address several times. The device configuration can remain stable. Conversely, many customers behind Australian mobile networks or corporate NAT can share one public address, so IP address alone is especially weak.

The local digital market is dominated by globally supplied operating systems, browsers, search services and advertising platforms, often combined with Australian publishers and retailers. That mix creates common traits among users, but it also means a local site may transmit information to an overseas service. The relevant data can cross borders even when the page and the visitor are in Melbourne or Adelaide.

Under the federal Privacy Act 1988, organisations that collect personal information must follow the Australian Privacy Principles, including transparency, purpose limitation and security safeguards. The Office of the Australian Information Commissioner treats combinations that can reasonably identify someone as personal information. State and territory laws can add obligations, and businesses may also need to avoid misleading conduct under the Australian Consumer Law. A privacy policy that omits undisclosed fingerprinting can create exposure even if it includes a generic cookie notice.

Privacy controls and technical limits

Visitors have several controls, though none is absolute. Blocking third-party scripts can stop many shared-site measurements, while privacy-focused browser settings can randomise or restrict hardware signals. Disabling JavaScript prevents client-side collection but does not erase headers or other passive clues. Clearing site data removes stored cookies and identifiers, yet a fingerprint derived afresh can return on the next visit unless it is deliberately made less stable.

For a site operator, the defensible approach is to inventory every script, document the signals and purposes involved, apply data minimisation, and set a retention period for any resulting identifier. A consent mechanism should cover meaningful fingerprinting rather than merely announcing cookies after data has been collected. Security teams can also compare browser configurations in a controlled test to estimate how many traits their stack reveals.

The central fact is that visual simplicity does not imply technical simplicity. A one-link page can still expose a layered combination of browser, device and network characteristics, whether those traits are gathered by JavaScript or observed by the server. Its visitors may remain anonymous in a legal or everyday sense while still receiving a highly repeatable technical profile.