DEV Community: Sid Wudraq

Canvas, Audio and WebGL: analysis of fingerprinting technologies

Sid Wudraq — Tue, 17 Mar 2026 12:35:29 +0000

Today, websites don’t rely on cookies alone to recognize visitors. Even if you clear your history, switch IPs or use private browsing mode, your browser can still be identified through a digital fingerprint. This is a hidden set of technical signals that gets generated automatically on every visit.

A browser fingerprint is a combination of parameters that describe your device and runtime environment. Individual attributes like browser version, screen resolution or language are shared by many users. But when combined, they form a highly distinctive profile. This profile is calculated in real time as the page loads, so it doesn’t depend on stored data. That’s why clearing cookies or using incognito mode doesn’t really change much.

Beyond basic indicators such as user agent, timezone or interface language, modern fingerprinting relies on more advanced techniques like Canvas, AudioContext and WebGL. These methods use the browser’s graphics and audio stack to extract deeper information about your hardware and system. What makes them so accurate, and how do they actually distinguish one device from another? Let’s take a closer look.

Canvas fingerprinting

The Canvas API allows browsers to render graphics using JavaScript. In fingerprinting, this feature is used in a less obvious way. A script on a webpage creates an invisible canvas element and executes a series of drawing commands, such as rendering text, shapes, shadows, and gradients. The resulting image is then read as pixel data and converted into a hash that acts as a unique identifier.

Here’s how the process works in practice:

Canvas creation. The page dynamically creates a canvas element, usually outside the visible area.
Drawing. JavaScript draws test graphics. This often includes text with specific fonts, geometric shapes, lines, shadows, and gradients to trigger different rendering behaviors.
Reading the pixels. The script reads the output using methods like toDataURL(), which converts the canvas content into a string representation of the image.
Hashing. The data is passed through a hashing function, producing a fingerprint that gets sent to the server.

Let’s draw the word “Fingerprint” on a Canvas and compute a primitive hash:

let canvas = document.createElement("canvas");
let ctx = canvas.getContext("2d");
canvas.width = 200; canvas.height = 50;

ctx.textBaseline = "top";
ctx.font = "20px Arial";
ctx.fillStyle = "#f60";
ctx.fillText("Fingerprint", 10, 10);

let data = canvas.toDataURL();
let hash = 0;
for (let i = 0; i < data.length; i++) {
  hash = (hash << 5) - hash + data.charCodeAt(i);
  hash |= 0;
}
console.log("Canvas hash:", hash);

This code outputs a 32-bit number (it can be negative due to overflow) that depends on how exactly the browser renders the text. In a different browser, like Opera in this example, the result may change. Sometimes it can match, but that’s relatively rare.

On a different machine, the chances of getting a different result are even higher, although matches are still possible in edge cases.

As shown in the screenshots below, even on the same device but across different browsers, the hash is not the same. In one case, the word “Fingerprint” was rendered in Chrome, and in the other, in Opera. You can try running this on your own machine and compare the results.

The differences in a Canvas hash don’t come from the text itself. Visually, the word “Fingerprint” looks the same on almost any device. The uniqueness comes from how it’s rendered under the hood.

Every OS and browser handles font smoothing, curves, hinting, and rasterization a bit differently. Then you add GPU differences, drivers, and hardware quirks, and you end up with tiny variations in the final image. On one device a pixel might be slightly lighter, on another slightly darker, or edges may be smoothed in a different way. You won’t notice it visually, but the hash will.

To increase entropy, websites don’t just render simple text. They often use strings that cover most of the alphabet, like “Cwm fjordbank glyphs mute quiz”. On top of that, they may add shadows, gradients, or colored shapes to extract more pixel-level differences.

The result is a stable hash string (something like e3d52382d0…) that stays consistent across visits, as long as the browser environment doesn’t change. In theory, two machines with identical fonts, GPUs, and drivers could produce the same fingerprint, but in reality that almost never happens. The combination of rendering factors is almost always unique, which makes Canvas a very effective tracking method.

AudioContext fingerprinting

Another way to generate a unique device identifier is audio fingerprinting. This method uses the Web Audio API, but not for recording from a microphone or playing sound. Everything happens entirely inside the browser, and the user doesn’t notice a thing.

The script generates and processes a synthetic audio signal, then extracts numeric values that reflect characteristics of the hardware and software environment. The result is a stable “audio” identifier, similar to a Canvas hash, but based on sound data.

Here’s the idea behind it:

AudioContext. The script initializes a hidden audio context, usually an OfflineAudioContext. Think of it as a virtual sound processor that runs calculations in memory without sending anything to your speakers.
Signal generation. Inside this context, an oscillator (like OscillatorNode) produces a signal at a fixed frequency, often around 1000 Hz. This is a clean, synthetic tone generated directly in the browser.
Effects processing. To make differences more noticeable, the signal is passed through effects. A common choice is a compressor (DynamicsCompressorNode), which alters the waveform. By tweaking parameters like threshold, ratio, attack, and release, the output becomes dependent on the system.
Rendering and reading. The audio context processes a short chunk of sound. Once rendering is done, the script gets an array of sample values. For example, at 44,100 Hz over ~0.1 seconds, that’s around 5,000 data samples.
Fingerprint computation. The sample array is reduced to a compact number. One simple approach is summing the absolute values and taking the most significant digits. That number becomes the audio fingerprint.

Here’s a simple example you can run in your browser console to generate your own audio fingerprint:

(async () => {
  const AC = window.OfflineAudioContext || window.webkitOfflineAudioContext;
  const ctx = new AC(1, 5000, 44100);

  const osc = ctx.createOscillator();
  osc.type = 'triangle';
  osc.frequency.value = 1000;

  const comp = ctx.createDynamicsCompressor();
  comp.threshold.value = -50;
  comp.knee.value = 40;
  comp.ratio.value = 12;
  comp.attack.value = 0;
  comp.release.value = 0.25;

  osc.connect(comp);
  comp.connect(ctx.destination);
  osc.start(0);

  const rendered = await ctx.startRendering();

  const samples = rendered.getChannelData(0);

  let acc = 0;
  for (let i = 0; i < samples.length; i++) acc += Math.abs(samples[i]);
  const demo = Math.round(acc * 1e6) / 1e6;

  const buf = samples.buffer.slice(
    samples.byteOffset,
    samples.byteOffset + samples.byteLength
  );
  const hashBuf = await crypto.subtle.digest('SHA-256', buf);
  const hashHex = Array.from(new Uint8Array(hashBuf))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');

  console.log('Audio demo sum:', demo);
  console.log('Audio SHA-256 :', hashHex);
})();

The same device usually produces the same audio fingerprint across different browsers. For example, in Chrome and Opera the resulting value matched (in our case, 953.152941). You can run the script yourself and check your own result.

Browsers have started to introduce protections against this kind of tracking. Apple was one of the first to implement it: начиная с Safari 17, the browser adds slight randomness to audio processing in private mode, which makes the fingerprint change from session to session.

In most other browsers, audio fingerprints can still be collected without much difficulty. When combined with Canvas and WebGL, they significantly increase the accuracy of device identification.

WebGL fingerprinting

HTML5 WebGL gives the browser access to hardware-accelerated 3D rendering through a canvas element with a WebGL context. It was originally designed for interactive graphics, but over time it has also become a powerful source of fingerprinting data.

While Canvas captures differences in 2D rendering, WebGL goes deeper and operates at the GPU level. Because of this, it can reveal much more about the system, including the graphics card model, driver version, and subtle details of how a specific GPU behaves. In some cases, it can even distinguish between two machines with the same graphics hardware.

A typical WebGL fingerprint is built in a few steps.

First, the script initializes a WebGL context, for example via canvas.getContext("webgl2"). At this stage, it can already access some basic environment data like the GPU vendor and renderer, driver details, and supported extensions.

Next comes rendering. A hidden canvas is used to draw a 3D scene or a set of primitives. This usually involves shapes, shaders, lighting, and textures — enough to engage different parts of the graphics pipeline.

Once rendering is complete, the script collects the output. It reads pixel data using methods like gl.readPixels and queries various WebGL parameters such as supported extensions, maximum texture size, shader precision, and VENDOR/RENDERER strings. Together, these values form a kind of snapshot of the graphics environment.

Finally, all collected data is combined and hashed, often using something like SHA-256. The resulting hash becomes the WebGL fingerprint, which can then be sent to the server and reused to identify the same device across sessions.

Here’s a simplified example of how such a hash can be generated:

(async () => {
  const cv = document.createElement('canvas');
  cv.width = 400; cv.height = 200;
  const gl = cv.getContext('webgl2', {antialias:true})
        || cv.getContext('webgl', {antialias:true});
  if (!gl) { console.log('WebGL недоступен'); return; }

  const info = {};
  const dbg = gl.getExtension('WEBGL_debug_renderer_info');
  if (dbg) {
    info.vendor = gl.getParameter(dbg.UNMASKED_VENDOR_WEBGL);
    info.renderer = gl.getParameter(dbg.UNMASKED_RENDERER_WEBGL);
  } else {
    info.vendor = '(masked)';
    info.renderer = '(masked)';
  }
  info.version = gl.getParameter(gl.VERSION);
  info.glsl = gl.getParameter(gl.SHADING_LANGUAGE_VERSION);
  info.maxTex = gl.getParameter(gl.MAX_TEXTURE_SIZE);

  const vs = `
    attribute vec2 p;
    void main(){ gl_Position = vec4(p,0.0,1.0); }
  `;
  const fs = `
    precision highp float;
    uniform vec2 u_res;
    float h(vec2 v){
      float s = sin(dot(v, vec2(12.9898,78.233))) * 43758.5453;
      return fract(s);
    }
    void main(){
      vec2 uv = gl_FragCoord.xy / u_res;
      float r = h(uv + vec2(0.11,0.21));
      float g = h(uv*1.3 + vec2(0.31,0.41));
      float b = h(uv*1.7 + vec2(0.51,0.61));
      gl_FragColor = vec4(pow(vec3(r,g,b)*(0.6+0.4*uv.x), vec3(1.1)), 1.0);
    }
  `;

  function sh(type, src){
    const s = gl.createShader(type);
    gl.shaderSource(s, src); gl.compileShader(s);
    if (!gl.getShaderParameter(s, gl.COMPILE_STATUS))
      throw new Error(gl.getShaderInfoLog(s)||'shader error');
    return s;
  }
  const pr = gl.createProgram();
  gl.attachShader(pr, sh(gl.VERTEX_SHADER, vs));
  gl.attachShader(pr, sh(gl.FRAGMENT_SHADER, fs));
  gl.linkProgram(pr);
  if (!gl.getProgramParameter(pr, gl.LINK_STATUS))
    throw new Error(gl.getProgramInfoLog(pr)||'link error');
  gl.useProgram(pr);

  const buf = gl.createBuffer();
  gl.bindBuffer(gl.ARRAY_BUFFER, buf);
  gl.bufferData(gl.ARRAY_BUFFER, new Float32Array([-1,-1, 3,-1, -1,3]), gl.STATIC_DRAW);
  const loc = gl.getAttribLocation(pr, 'p');
  gl.enableVertexAttribArray(loc);
  gl.vertexAttribPointer(loc, 2, gl.FLOAT, false, 0, 0);

  const ures = gl.getUniformLocation(pr, 'u_res');
  gl.uniform2f(ures, gl.drawingBufferWidth, gl.drawingBufferHeight);

  gl.viewport(0,0,gl.drawingBufferWidth, gl.drawingBufferHeight);
  gl.clearColor(0,0,0,1); gl.clear(gl.COLOR_BUFFER_BIT);
  gl.drawArrays(gl.TRIANGLES, 0, 3);

  const w = gl.drawingBufferWidth, h = gl.drawingBufferHeight;
  const px = new Uint8Array(w*h*4);
  gl.readPixels(0,0,w,h, gl.RGBA, gl.UNSIGNED_BYTE, px);

  const enc = new TextEncoder();
  const meta = enc.encode(JSON.stringify(info));
  const full = new Uint8Array(meta.length + px.length);
  full.set(meta, 0); full.set(px, meta.length);

  const hashBuf = await crypto.subtle.digest('SHA-256', full.buffer);
  const hex = Array.from(new Uint8Array(hashBuf))
    .map(b=>b.toString(16).padStart(2,'0')).join('');

  let hi = 0>>>0, lo = 0>>>0;
  for (let i=0;i<px.length;i+=16){
    const a = px[i] | (px[i+1]<<8) | (px[i+2]<<16) | (px[i+3]<<24);
    hi = ((hi ^ a) + 0x9e3779b9) >>> 0;
    lo = ((lo ^ ((a<<7)|(a>>>25))) + 0x85ebca6b) >>> 0;
    hi ^= (hi<<13)>>>0; lo ^= (lo<<15)>>>0;
  }
  const sample64 = ('00000000'+hi.toString(16)).slice(-8)+('00000000'+lo.toString(16)).slice(-8);

  console.log('WebGL vendor  :', info.vendor);
  console.log('WebGL renderer:', info.renderer);
  console.log('WebGL version :', info.version, '| GLSL:', info.glsl);
  console.log('MAX_TEXTURE_SIZE:', info.maxTex);
  console.log('SHA-256(meta+pixels):', hex);
  console.log('Sample64:', sample64);
})();

Here's what we get:

So what exactly does WebGL capture?

First of all, GPU identifiers. Different graphics cards expose different capabilities. Integrated Intel Graphics differ from discrete NVIDIA GeForce or AMD Radeon in terms of memory, supported extensions, and driver behavior. All of this is reflected in the WebGL context parameters.

Then there are variations between seemingly identical devices. Even if two machines use the same GPU model, there can still be small hardware-level differences. WebGL can pick these up by measuring things like shader execution or by detecting subtle rendering artifacts at the pixel level.

The browser itself also plays a role. Different engines such as Blink, WebKit, and Gecko handle WebGL calls slightly differently, which leads to small but consistent differences in the final output. That’s why the same WebGL fingerprint can vary across browsers, even on the same machine.

WebGL fingerprints are often combined with Canvas and audio data for more robust tracking, but even on their own, they can reveal a surprisingly detailed picture of a user’s system.

How to reduce fingerprinting risks

Completely eliminating all fingerprinting vectors is almost impossible. There are simply too many signals a website can collect. Still, you can reduce how unique your setup looks and make tracking more difficult.

One approach is using hardened browsers and privacy modes. Tor Browser is designed so that all users look the same. It restricts Canvas and WebGL and standardizes many environment parameters. This is effective, but often breaks modern websites.

Brave Browser blocks many common fingerprinting techniques.
Safari, in private browsing, adds noise to audio processing, making audio fingerprints less stable.

Another option is blocking or spoofing extensions like CanvasBlocker. They prevent websites from reading Canvas data or return modified images. Similar tools exist for AudioContext. The downside is that very few users run these setups, so this kind of behavior can actually stand out. A completely blank Canvas or constantly changing noisy hash may look suspicious rather than anonymous.

There’s also the idea of reducing uniqueness by standardizing the environment. For example, running a browser inside a virtual machine or cloud environment where multiple users share the same configuration. Some anti-fraud systems use similar approaches. In practice, though, this is not very convenient for everyday use.

A more balanced approach is controlled spoofing. Anti-detect browsers allow you to configure your environment in a way that looks realistic rather than random. Instead of blocking signals, they make them consistent and plausible.

For example, Octo Browser lets you control what websites see in terms of Canvas, WebGL, and audio data. It introduces subtle, realistic variations and aligns parameters so that each profile look plausibly unique without standing out among millions of other users.

You can try Octo Browser for free using promo code DEVTO.

If your goal is maximum anonymity, you would need to constantly rotate devices, browsers, and configurations, while keeping everything updated and minimizing extra signals. Even then, it only reduces risk to a certain extent. In practice, using specialized tools that manage fingerprints in a consistent and realistic way is often a more effective approach.

How Browser Fingerprinting Works

Sid Wudraq — Mon, 02 Feb 2026 12:24:28 +0000

Browser fingerprinting is a way to identify a user based on technical details of their device and browser, without using cookies. When you visit a website, a script collects basic information such as your operating system, browser version, language, time zone, screen settings, fonts, and other parameters. Together, these details form a digital “fingerprint” that allows the website to recognize you on future visits — even if you clear cookies or use incognito mode.

This fingerprint is not 100% unique, but it is accurate enough (about 85–90%) to reliably identify the same user. Because a fingerprint is made up of many parametres, changing just one or two settings usually does not help. To really avoid tracking, the entire fingerprint configuration has to be changed, not individual parameters.

What makes up a browser fingerprint?

A digital fingerprint is made up of many small parameters that together create an almost unique profile of a device. Some of this data is sent automatically by the browser with each HTTP request (passive parametres). Other data is collected on the client side using JavaScript and various Web APIs (active parametres).

Passive parameters (HTTP headers and connection)

IP address

Every request to a website contains the device’s source IP address. It can be used to determine an approximate location (country, city, ISP) via WHOIS and GeoIP databases. Although an IP address is often shared by multiple users of the same provider and may change over time, it remains a core network signal in a browser fingerprint. If WebRTC is available, a script can reveal the real IP via a STUN request, making identification even more accurate. On its own, an IP is rarely stable, but combined with other signals it significantly increases uniqueness.

User-Agent

The browser sends a User-Agent string that describes the browser type and version, operating system, architecture, and sometimes the device model:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36
The User-Agent helps quickly classify a user by browser and platform. While it is easy to spoof, in real-world fingerprints it is still one of the key attributes. Some extensions also add their own headers, which can reveal installed plugins or frameworks. Uncommon combinations of operating systems and browser versions are more likely to stand out and expose the user.

Accept headers

With every request to a server, the browser automatically sends a set of HTTP headers: which content types it can handle (Accept), which languages it prefers (Accept-Language), which compression methods it supports (Accept-Encoding), as well as cache-related headers, referrer information, and other technical details. Taken together, these values can be highly informative.

For example, differences in the order of locales listed in Accept-Language or character sets in Accept-Charset can reveal specific system or regional settings. Support for Brotli compression, shown by Accept-Encoding: br, usually indicates a modern browser. The exact order in which headers are sent is also often tied to a particular browser engine—different browsers construct and transmit headers in slightly different sequences, which becomes an additional identifying signal.

All of this data falls into the category of passive signals: no scripts are required to collect it, as the browser sends it automatically. Based on these headers, a server can infer the client type (for example, from the User-Agent), preferred interface languages, supported image formats, and more. All of these details ultimately become part of the overall browser fingerprint.

Supported technologies

Some headers indicate the capabilities of the browser—for example, DNT (Do Not Track) or Upgrade-Insecure-Requests. Having DNT enabled is relatively rare and can make a profile more noticeable. These attributes are seldom used on their own, but when combined with other signals, they contribute to the overall uniqueness of the browser fingerprint.

Timezone

The most accurate way to determine a user’s timezone is through an active method using JavaScript, which directly returns the offset from UTC. Even without scripts, the server can make an approximate estimate—for example, by comparing the Date header or log timestamps with client-side data like If-Modified-Since. Differences in time can sometimes reveal the user’s timezone.

Usually, the timezone is obtained directly from the browser, providing a precise value. The offset from GMT (for example, GMT+3) is a stable characteristic: it varies between regions and generally stays the same for a single device unless the user travels or manually changes the settings.

Active parameters (JavaScript and Web APIs)

Screen resolution and color depth

These parameters are read via the window.screen object. The screen.width and screen.height properties show the available screen resolution (sometimes already adjusted for system scaling), while screen.colorDepth indicates color depth—most commonly 24 or 32 bits. These values are almost always included in a browser fingerprint because there are many possible combinations, and users’ displays vary widely.

On desktop devices, the browser window size usually does not match the actual screen size, so fingerprinting systems typically use the maximum available resolution, which reflects the real monitor settings.

Common combinations like 1920×1080×24 or 1366×768×24 already help split devices into distinct groups. Any change in setup—such as switching monitors, changing resolution, or connecting a second display—updates these values and, as a result, changes the overall fingerprint.

Language settings

Browsers have several language-related parameters: the system interface language, the preferred language for websites, and the locale, which determines date, number, and other regional formats. These values can be accessed via JavaScript, for example through navigator.language or navigator.languages. Values like "ru-RU" or "en-US" usually match what the server receives in the Accept-Language header. The locale also affects how the browser displays dates—month names, time format, and other elements—which provides an additional signal for trackers.

In terms of uniqueness, language settings add noticeable variation. A user might have a Russian system interface (ru-RU), a Ukrainian one (uk-UA), or an English interface (en-US) while still being a Russian speaker.

While common languages are shared by many users and don’t provide absolute uniqueness on their own, in combination with other characteristics they help create distinct profiles. For example, they can distinguish a Chrome on Windows with Russian locale from the same Chrome version on Windows with German settings.

Timezone (via JavaScript)

A timezone can be determined using new Date().getTimezoneOffset(), which returns the difference from UTC in minutes. For GMT+3, this value is around 180. The Intl API can also provide the timezone as a string identifier. Timezone is almost always included in a browser fingerprint because it is stable and clearly differentiates users from different regions. Even if other parameters match, different timezones result in different profiles.

Some advanced tracking systems monitor changes in this value, which can indicate that the browser is the same but the user has changed time settings. In standard fingerprinting, however, only the current offset is usually taken into account.

Platform and CPU information

Websites can obtain a range of technical details about a device through the navigator object.

navigator.platform returns a string indicating the operating system or architecture, such as Win32, Linux x86_64, or iPhone. In the past, this parameter clearly distinguished platforms, but modern browsers often mask it for privacy reasons. When available, it becomes part of the fingerprint.
navigator.hardwareConcurrency reports the number of logical CPU threads. On mobile devices this is usually 4–8, while on desktops it can be 4, 8, 12, 16, or more. Unusual values like 6 or 10 tend to stand out and make a device more distinctive.
navigator.deviceMemory provides an approximate amount of RAM in gigabytes (in Chrome it is usually rounded, for example to 8). This parameter is not supported everywhere, but when present it significantly increases fingerprint variability.
navigator.oscpu is Firefox-specific and largely duplicates OS information, so it is rarely used.
navigator.webdriver indicates whether the browser is being controlled by automation. It does not add entropy to the fingerprint, but a true value clearly separates automated browsers from regular users, indirectly contributing to identification.

Cookies and Web Storage

Checking navigator.cookieEnabled shows whether cookies are disabled. This is quite rare and can serve as a distinguishing signal.

Plugin list

navigator.plugins is almost empty in most modern browsers, but its state (full, partial, or empty) can still be used. In the past, the plugin list provided very high uniqueness; today it is more of an auxiliary signal.

Installed extensions

Although browsers do not directly expose a list of installed extensions, many can be detected indirectly. Ad blockers reveal themselves by blocking specific requests or modifying the DOM. Some extensions leave unique objects on the window object, making them easy to identify. A combination of such signals allows a website to build an approximate profile of installed extensions. Even a single popular ad blocker or password manager can noticeably increase fingerprint uniqueness.

Installed fonts

The set of system fonts varies greatly depending on the operating system, installed software, and locale, which makes it a strong source of uniqueness. Available fonts can be detected without Flash, using CSS+JS or Canvas.

With CSS, a hidden element is assigned a font stack and its dimensions are measured—changes indicate whether a specific font is installed. A faster approach uses Canvas: text is rendered with a chosen font, and pixel differences reveal its presence. Since there are countless font combinations and rare fonts stand out immediately, this parameter is especially valuable for fingerprinting.

Canvas fingerprinting

This is one of the most well-known fingerprinting techniques, based on how a device renders graphics in the HTML5 element. A script draws text and simple shapes, then reads the result via canvas.toDataURL() and converts it into a hash—the Canvas fingerprint.

Uniqueness comes from many subtle differences: font rendering and anti-aliasing, driver versions, operating system, and graphics hardware. Even with identical code, two devices almost always produce slightly different bitmaps.

Typically, scripts draw text with various characters or add colored shapes and shadows to trigger as many rendering features as possible. The fingerprint may change after driver updates or a GPU change, but together with WebGL it remains one of the most informative signals.

WebGL fingerprinting

WebGL provides access to graphics subsystem data, which is why it is widely used for fingerprinting. Through the WEBGL_debug_renderer_info extension, a website can obtain the GPU vendor and model—essentially a direct identifier of the graphics card, which greatly increases profile uniqueness.

Even without exposing the adapter name, WebGL returns many numeric parameters that depend on drivers and hardware, such as buffer sizes, the number of supported textures, and shader limits. By collecting these values, trackers build a characteristic “capability vector” of the device.

Similar to Canvas fingerprinting, a scene can also be rendered and the output hashed to detect even subtler differences. When combined with Canvas, WebGL becomes one of the strongest fingerprinting signals, which is why privacy-focused browsers try to hide or distort this data.

AudioContext fingerprinting

This method uses the Web Audio API to generate a unique “audio fingerprint.” Different combinations of browser, operating system, and hardware process and generate sound slightly differently due to variations in audio libraries, drivers, and floating‑point calculations. These tiny differences produce a stable but distinctive result for each device.

An audio fingerprint strengthens overall identification: even if Canvas and WebGL fingerprints match, audio data often makes it possible to tell two otherwise similar profiles apart.

Media devices and sensors

Scripts can also collect information about connected hardware. Using navigator.mediaDevices.enumerateDevices(), a site can determine the number of cameras and microphones— even without device names, this already adds a fingerprinting signal.

In the past, additional APIs such as the Battery Status API were used to expose battery level and remaining time, but they were restricted due to privacy concerns.

Motion and orientation sensors provide further differences: update frequency, the presence of specific sensors, and data formats vary between devices. These signals are especially noticeable on uncommon hardware. In practice, dozens of such parameters are combined into a structured dataset and hashed (for example, with MurmurHash) to produce a short device identifier.

Is there any protection against browser fingerprinting?

Modern browsers try to reduce the amount of data that can be collected. Tor Browser makes users as similar as possible by using a unified User‑Agent, a fixed window size, a limited set of fonts, and by restricting Canvas and AudioContext. Firefox offers the privacy.resistFingerprinting mode, which also standardizes many parameters. Brave blocks trackers by default and adds noise to key APIs. There are also extensions like CanvasBlocker or Privacy Badger that disrupt fingerprint collection in specific areas. Still, full protection is not possible — browsers inevitably expose too much information.

At the same time, anti‑detect browsers are evolving. Tools like Octo Browser, MultiLogin, and Dolphin Anty allow users to modify fingerprints and create multiple isolated profiles. They are widely used in web scraping, automation, digital marketing and other spheres where it's important to avoid browser fingerprinting.

You can try Octo Browser using the promo code DEVTO, which gives 4 days of free trial.