Check a profile's fingerprint
Run LoginDeck's own check to see what the browser really reports, compared with what the profile claims β then confirm it at an outside detector.
On this page
The Fingerprint check launches the profile exactly as a normal run does β its real flags, its real proxy β reads the browser the way a detector would, and compares every trait against what the profile says it is. It is the fastest way to answer "is this profile actually doing what I set up".
π Run a check#
- In All profiles, open the row's β― menu and click Fingerprint check.
- Wait. The check takes about fifteen seconds and shows what it is doing: launching the engine bare so there is something honest to compare against, launching your profile, reading the browser, then comparing.
- Read the report.
A browser window opens and closes by itself while it runs. That is not your profile's session β the check uses a scratch folder, so nothing it does can reach the cookies and logins the profile already has, and it can run while the profile is open.
You can also start one from inside the editor: the header has a Fingerprint check button on saved profiles. With unsaved edits it asks Save first?, because a check launches the profile as it is on disk, not as it is on screen β Save and check does both.
π Reading the report#
Four counters sit at the top:
| Counter | Meaning |
|---|---|
| as configured | The browser reported what the profile claims. |
| wrong today | A contradiction a detector would see. Worth acting on. |
| needs the engine | A trait that only LoginDeck's own browser engine can change. It turns green when the profile runs on that engine. |
| for information | Context, or a reading the check could not settle either way. |
Under them, a line of facts: Engine (LoginDeck, or stock Chrome), Proxy, Exit (address, city, country), Clock, and how long ago the run was.
Then the rows themselves, grouped:
- Identity β user agent,
navigator.platform, client hints, language list, browser version. - Hardware β CPU threads, memory, WebGL vendor and renderer, screen and window size, the font set against the claimed operating system, media devices. Phone profiles add touch points, pointer queries, pixel ratio, orientation, viewport and the mobile client hints.
- Location β the exit address, where it is, the browser's timezone, whether the timezone matches the exit, whether the clock agrees with its own zone.
- Automation and leaks β
navigator.webdriver, WebRTC addresses, Do Not Track, plugins, the PDF viewer,window.chrome, permission consistency. - Masking (against the same engine launched bare) β canvas, canvas stability, WebGL image, audio, client rects, WebGL metadata and the font list, each compared with the same engine launched with no profile settings at all. "Different from the unconfigured browser on the same computer" is the only comparison that means anything.
Each row shows what the profile says, what the browser reported, a verdict, and a sentence explaining the verdict where one is needed.
Start with the failures
A short list of "wrong today" rows is the whole to-do list. The most common one is Timezone vs exit IP β the clock and the address disagree, which is the single loudest location signal there is.
π Confirm it somewhere else#
Our report agreeing with itself proves nothing. On the same screen, Open a detectorβ¦ opens the real profile β its cookies, its proxy β at somebody else's test:
- CreepJS
- iphey
- Pixelscan
- BrowserScan
- BrowserLeaks WebRTC
Use these before you trust a profile with an account that matters.
π οΈ When the check will not finish#
The screen says The check could not finish and gives the reason.
- a check is already running for this profile β one at a time. Wait for the first to finish.
- the browser closed before it finished reading itself β the browser died during the run. Try A profile won't start, which covers the same failures.
Press Run again to retry, or Back to return to the list.
βΉοΈ Good to know#
- The full report is not saved. Leave the screen and it is gone; Run again rebuilds it.
- On Windows, if the Browser timezone row fails, the note explains that Chromium on Windows does not honour the environment variable that carries the zone.
- Firefox profiles are checked with Firefox-appropriate rows. The masking hashes are reported for information rather than compared, because a Firefox render shares nothing with the Chromium baseline.
- A profile that is locked by your plan cannot be checked, because a check is a launch. See plan limit messages.
- What a "needs the engine" row means, and which traits no browser can fix at all, is covered in What no antidetect browser can change.