Parameter reference
This page covers every fingerprint parameter that the Maskifi editor lets you configure. Fields are grouped by the editor's collapsible sections.
Before diving into individual fields, it helps to understand the field modes — the toggle next to each field that controls how the value is determined.
Field modes
Each editable parameter in the fingerprint editor has a small mode selector next to its label. The available modes depend on the field, but the options are always drawn from this set:
| Mode | What it means |
|---|---|
| Custom | You set the value explicitly. The value is saved with the profile and applied every time the browser launches. Use this when you need precise control — for example, to match a specific operating system or a specific screen size. |
| Real | No override is applied. The browser uses the host device's actual value for that attribute. Useful when you do not need to disguise that attribute — for example, if you are running profiles that are allowed to share a timezone with the host machine. |
| By IP | The value is derived automatically from the proxy's IP address at launch time. Available for Timezone, Geolocation, and WebRTC. This is the safest default for those fields because it keeps the fingerprint consistent with where the IP geolocates — no manual coordination needed. |
| Block | The browser denies any page that tries to read this attribute. Available for Geolocation. The page receives a permission-denied error rather than a fabricated value. |
| Disabled | The feature is turned off at the browser level. Available for WebRTC. When WebRTC is disabled, the browser cannot perform WebRTC connections, so there is no address to leak. |
When you switch a field away from Custom, the stored value is cleared from the profile. Switching back to Custom requires re-entering a value or regenerating the fingerprint.
Navigator section
These fields control how the browser identifies itself — both to web pages and in outgoing network requests. They are the most commonly checked signals and must be mutually consistent.
User-Agent
What it is. The browser identification string that the browser reports to every website. It includes the browser name and version, the rendering engine version, and the operating system.
Why it matters. User-Agent is checked by virtually every site. It must be consistent with Platform, the operating system in the Languages header, and the actual browser capabilities. A mismatch — for example, claiming to be Chrome on macOS while Platform says Windows — is an immediate red flag.
Modes. Custom, Real.
Input. Free-text. Example: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0. When you change the User-Agent, the corresponding network request header is updated automatically so the two values always match.
Language
What it is. The primary language tag reported to web pages — the first and most prominent entry in the browser's language preference list.
Why it matters. A profile's primary language should match its proxy region. A profile claiming to be in Japan but reporting en-US as its language is plausible (many people browse in English from non-English countries) but uncommon enough to be worth considering. Platforms enforcing regional restrictions pay close attention to this.
Modes. Custom, Real.
Input. Free-text BCP 47 language tag. Examples: en-US, de-DE, ja-JP.
Languages
What it is. The full ordered list of language tags that the browser accepts. Web pages receive this as a priority-ordered list; it is also reflected in the HTTP Accept-Language request header.
Why it matters. Real browsers accumulate several language tags over time — a primary language, its neutral form, and sometimes secondary languages. A profile with only en-US in its list looks slightly different from one with en-US, en or en-US, en, fr. The list should be realistic for the persona you are building.
Modes. Custom, Real.
Input. One tag per entry (press Enter after each). The list is saved in order.
Platform
What it is. The platform identifier string that the browser reports to web pages — a short string indicating the operating system family and architecture.
Why it matters. Platform must agree with the operating system implied by the User-Agent string. Disagreement between these two values is a well-known detection signal.
Modes. Custom, Real.
Options.
| Option | Meaning |
|---|---|
| Win32 | Windows (32-bit processes, regardless of whether the OS is 64-bit) |
| Win64 | Windows (64-bit native process) |
| MacIntel (Intel) | macOS on an Intel processor |
| MacArm64 (Apple Silicon) | macOS on an M-series (Apple Silicon) processor |
| Linux x86_64 | Linux on a 64-bit Intel/AMD processor |
| Linux i686 | Linux on a 32-bit x86 processor |
| Linux aarch64 | Linux on a 64-bit ARM processor |
CPU Cores
What it is. The number of logical CPU cores the browser reports to web pages.
Why it matters. CPU core count is one of the easiest hardware signals to read and it correlates strongly with the claimed device type. A profile claiming to be a low-end laptop but reporting 16 cores, or a high-end workstation reporting 2, looks unusual. Core count should be plausible for the operating system and device class the profile is presenting.
Modes. Custom, Real.
Options. 2, 4, 6, 8, 12, 16.
Do Not Track
What it is. The Do Not Track signal that the browser sends to websites — a declaration of whether the user prefers not to be tracked.
Why it matters. Most real browsers leave Do Not Track unset (the default). A profile with Do Not Track explicitly enabled is a small but measurable distinguishing detail — most users never touch this setting. Setting it to "not set" is the most common real-world state.
Modes. Custom, Real.
Options.
| Option | Meaning |
|---|---|
| Enabled (1) | Browser reports DNT: 1 — user has opted out of tracking |
| Disabled (0) | Browser reports DNT: 0 — user has explicitly opted in to tracking |
| Not Set | No DNT header is sent — the most common real-world state |
Touch Points
What it is. The maximum number of simultaneous touch points the device reports supporting.
Why it matters. Touch support reveals the device type. A value of 0 means no touchscreen — consistent with a conventional desktop or laptop. Higher values indicate a touch-capable device such as a tablet or touchscreen laptop. This must match the rest of the device profile: a Windows desktop claiming 10 touch points, or a claimed MacBook Pro claiming 5, looks off.
Modes. Custom, Real.
Options.
| Option | Typical use |
|---|---|
| 0 (no touch) | Desktop or laptop without a touchscreen |
| 1 | Single-touch device |
| 5 | Basic multi-touch tablet or touchscreen |
| 10 | Full multi-touch device (e.g. modern tablet or convertible laptop) |
Screen section
These fields control the screen and window dimensions the browser reports. Tracking systems frequently correlate resolution, display scale, and window size to detect spoofed environments.
Resolution
What it is. The reported screen width and height in physical pixels.
Why it matters. Screen resolution is one of the most collected fingerprint attributes. It must be plausible for the claimed platform and device type. A profile claiming to be a Linux server workstation but reporting a 4K display, or a claimed MacBook Air with a 1280×720 resolution, can stand out. Resolution also constrains the window size fields — Maskifi updates all related dimensions together so they stay consistent (available screen area, outer window, inner viewport).
Modes. Custom, Real.
Options. Common preset resolutions:
| Option |
|---|
| 1920 × 1080 (Full HD, most common) |
| 1366 × 768 |
| 1536 × 864 |
| 1440 × 900 |
| 1280 × 720 |
| 1680 × 1050 |
| 1600 × 900 |
| 1280 × 800 |
| 1280 × 1024 |
| 2560 × 1440 (QHD) |
| 3840 × 2160 (4K UHD) |
If the fingerprint already contains a resolution not in this list (for example, one set by a previous generation), it appears as an additional entry at the top.
Device Pixel Ratio
What it is. The ratio of physical screen pixels to CSS (logical) pixels — essentially, how many hardware pixels make up each "pixel" in web page layout.
Why it matters. Device pixel ratio correlates strongly with screen resolution and hardware type. A display scale of 2 or higher (HiDPI/Retina) implies a high-resolution display. Using a ratio of 2 with a 1366×768 resolution, or a ratio of 1 with a 3840×2160 resolution, creates an immediately suspicious combination.
Modes. Custom, Real.
Options. 1, 1.25, 1.5, 2, 3.
Color Depth
What it is. The number of bits used to represent the color of each pixel on screen, as reported to web pages.
Why it matters. Almost all modern displays report 24-bit color. Values of 30 or 32 bits indicate professional or high-end displays. The reported color depth should match what is plausible for the claimed hardware.
Modes. Custom, Real.
Options. 24 bit (standard), 30 bit, 32 bit.
WebGL section
These fields control the GPU identity the browser reports through the graphics API. GPU signals are among the most reliable hardware identifiers that websites can read.
WebGL Vendor
What it is. The graphics card manufacturer name reported through the graphics API.
Why it matters. GPU vendor is highly correlated with operating system and device class. Apple Silicon Macs report Apple's GPU. Windows desktops commonly report NVIDIA, AMD, or Intel. Linux machines may report Mesa. The vendor string should be plausible for the claimed OS and hardware profile. When WebGL Vendor is set to Custom, the renderer string shown to pages is overridden; the underlying GPU capability data (supported features, extension list, shader precision) is generated automatically and shown read-only in the Technical Data section.
Modes. Custom, Real.
Input. Free-text. Example: Google Inc. (NVIDIA).
WebGL Renderer
What it is. The specific graphics card model and driver description reported through the graphics API.
Why it matters. The renderer string identifies the exact GPU model (for example, ANGLE (NVIDIA GeForce GTX 1060 6GB Direct3D11 vs_5_0 ps_5_0)). This is one of the most granular hardware signals available to web pages. The renderer must be consistent with the vendor string and with the broader hardware profile. Mismatched vendor/renderer pairs — or renderer strings that have never appeared on real devices — are reliably caught by fingerprint databases.
Modes. Custom, Real.
Input. Free-text. Example: ANGLE (NVIDIA GeForce GTX 1060 6GB Direct3D11 vs_5_0 ps_5_0).
Timezone & Geolocation section
Location-related fields are the most common source of fingerprint-to-proxy inconsistencies. Maskifi's By IP mode eliminates that risk by deriving the values from the proxy automatically.
Timezone
What it is. The timezone name used by the browser for date and time calculations and exposed to web pages.
Why it matters. A profile's timezone must match the IP address's location. A proxy in New York with a Tokyo timezone is an obvious inconsistency. In By IP mode, Maskifi resolves the proxy's location at launch time and sets the timezone to match — no manual coordination required. If you need to pin a specific timezone (for example, to ensure a profile always behaves as a New York user even if the proxy changes), use Custom.
Modes. By IP (default), Custom, Real.
Input (Custom only). Searchable dropdown with all standard timezone names (e.g. America/New_York, Europe/Berlin, Asia/Tokyo).
Geolocation
What it is. The latitude, longitude, and accuracy that the browser returns when a web page requests the user's location via the browser location API.
Why it matters. Geolocation coordinates are extremely easy for a site to cross-check against the IP address. Returning coordinates inconsistent with the IP — or returning real device coordinates — is an immediate red flag. By IP mode calculates approximate coordinates from the proxy's IP. Block prevents the page from receiving any coordinates at all (the permission is denied). Custom lets you set exact coordinates.
Modes. By IP (default), Custom, Block.
Sub-fields (Custom only):
| Field | Range |
|---|---|
| Latitude | −90 to 90 (up to 6 decimal places) |
| Longitude | −180 to 180 (up to 6 decimal places) |
| Accuracy (m) | 1 to 10,000 metres |
WebRTC section
WebRTC IP
What it is. The IP addresses the browser exposes through the WebRTC protocol — both the public-facing address and the local network address.
Why it matters. WebRTC can leak the browser's real IP address even when all other traffic goes through a proxy, because WebRTC connections bypass the proxy's routing. This is one of the most common fingerprint failures. Maskifi gives you three strategies:
- By IP — WebRTC reports the proxy's IP address as both the public and local address. The leak still happens, but what leaks is the proxy IP rather than the real one.
- Custom — You set specific IPv4 and IPv6 addresses for both the public and local WebRTC identities. Use this when you need precise control over what WebRTC reveals.
- Disabled — WebRTC is turned off entirely at the browser level. No WebRTC connections can be made, so there is nothing to leak. This is the most conservative option; some services that rely on WebRTC (video calls, some streaming platforms) will not work.
Modes. By IP (default), Custom, Disabled.
Sub-fields (Custom only):
| Field | Example |
|---|---|
| IPv4 | 203.0.113.42 |
| IPv6 | 2001:db8::1 |
Media & Fonts section
Media Devices
What it is. The count of microphones, webcams, and speakers that the browser reports as available to web pages.
Why it matters. Web pages can enumerate how many media devices are present without requesting access to them. A profile with zero of each — which can happen with some default browser configurations — is unusual; most real devices have at least one speaker and one microphone. On the other hand, reporting an unusually high number (five cameras, ten microphones) also stands out. The reported counts should reflect what is realistic for the claimed device.
Modes. Custom, Real.
Sub-fields (Custom only): Separate number inputs for Microphones (0–10), Webcams (0–10), and Speakers (0–10).
Webcam Source
What it is. Controls what the browser camera API returns when a web page requests camera access.
Why it matters. When a site activates the camera (for example, for identity verification or video chat), the browser must return actual video frames. This field controls where those frames come from — your real camera, a pre-recorded video file, or nothing at all.
This field has its own mode toggle separate from the Media Devices mode:
| Option | What it does |
|---|---|
| Real | The browser passes through the host device's actual camera feed. |
| Custom video | The browser plays back a video file you select. The file must be in Y4M format. The file path is chosen at launch time via a system file picker, not stored in the profile directly. |
| Disabled | The browser reports no camera available, regardless of what the Media Devices count says. |
Fonts
What it is. The list of font family names reported as installed on the device.
Why it matters. Font enumeration is a well-established fingerprinting technique. The set of installed fonts is correlated with operating system, locale, and software installed on the device. A Windows profile with only macOS system fonts, or a profile with an impossibly comprehensive font collection spanning multiple OS defaults, is detectable. The font list should be realistic for the claimed OS and region. The engine also applies a per-profile spacing seed to introduce subtle rendering variation in font metrics, even for profiles with the same font list.
Modes. Custom, Real.
Input (Custom only). Tag-style input — type a font name and press Enter to add it. Example entries: Arial, Calibri, Georgia.
Technical Data section (read-only)
The Technical Data section at the bottom of the editor is collapsed by default. It shows additional fingerprint values that are generated automatically and cannot be edited individually:
- Navigator identity fields — legacy browser identity strings generated to match the User-Agent.
- HTTP headers — the full set of HTTP request headers the browser sends, including the User-Agent header and the Accept-Language header.
- Codecs — the audio and video codecs the browser reports as supported. These vary by browser version and are generated to match.
- WebGL technical data — GPU capability tables, shader precision formats, supported extensions list, and context attribute values. These are derived from the WebGL vendor and renderer settings and reflect real GPU capabilities for the claimed hardware.
These fields ensure internal consistency and are updated when you regenerate the fingerprint. They cannot be changed directly; if you need different values, change the relevant editable fields (WebGL Vendor/Renderer, User-Agent) and regenerate.
Auto-generated fields (not editable in the editor)
The following attributes are part of every Maskifi fingerprint but are not exposed as manual fields. They are always generated automatically to match the rest of the fingerprint:
- Canvas noise — a per-profile anti-aliasing offset applied at the browser rendering layer, producing unique canvas fingerprint output without requiring you to configure anything.
- Audio fingerprint — sample rate, output latency, and channel count are generated together with the hardware profile and shown read-only in the Technical Data section. They cannot be set individually in the editor.
- Speech synthesis voices — the list of text-to-speech voices available in the browser. Generated to match the claimed OS and locale.
- Battery state — charging state, charge level, charge time, and discharge time. Generated to form a consistent battery status; not exposed in the editor.
- Locale settings — the internal locale (language, region, script) used by the browser for date formatting and similar APIs. Derived from the Language field; not a separate editable field.
- Window scroll and position offsets — internal window geometry values that accompany the screen resolution. Updated automatically when you change the Resolution.
- WebGL2 capability data — the equivalent of WebGL technical data for the WebGL2 context. Generated alongside the WebGL fields.