Introduction
Your browser is a chatterbox. Ask it anything and it will happily list its version, your screen size, your language, your fonts. But it is not the first thing on your connection to say something about you.
Before a single line of JavaScript runs, before the page even decides what it looks like, your computer has already opened a TCP connection. And that very first packet does little more than knock on the door and say "Hello!" Even so, it already carries a faint accent. An accent of the operating system that sent it.
A server that knows how to listen can hear that accent and make a confident guess: Windows, something Apple, or something Linux. It never asked. It never sent a probe back. It just listened to a packet you were always going to send anyway. That is passive OS fingerprinting, and it is one of the quietest and most stubborn signals you give off online.
It matters because the operating system your connection reveals gets quietly compared against the operating system your browser claims. When a browser swears it is Chrome on Windows and the connection underneath speaks fluent Linux, that contradiction is the sound of a mask slipping. The rest of this article is about how that accent is read, why it is so hard to fake, and what your own connection is broadcasting right now.
What a TCP Handshake Reveals, in One Paragraph
Every secure connection starts with a TCP handshake, and the client speaks first with a packet called a SYN. That packet is assembled by your operating system's network stack, not by your browser, and different operating systems build it in subtly different ways. The starting hop limit, the receive window, the maximum segment size, the multiplier on that window, and above all the order the options are listed in are all defaults baked into the kernel. Read those fields together and you have a TCP fingerprint, a short signature of the network stack that sent the packet. Collapse it into a compact string and you have a JA4T fingerprint, the modern format for exactly this. This whole family of tricks is called TCP/IP stack fingerprinting, and it works without any cooperation from you, your browser, or a single byte of JavaScript.
The First Packet Has an Accent
Think of it less like reading someone's passport and more like recognising their handwriting. No single field is a unique identifier. Together, they fall into recognisable patterns, because each operating system family ships its network stack with its own house style.
A few of the giveaways a passive listener leans on:
| Signal | What it is | The typical tell |
|---|---|---|
| Initial TTL | The starting hop limit the OS stamps on outgoing packets. | 64 for Linux, macOS and iOS. 128 for Windows. 255 for routers. |
| Window size | How much data the OS offers to receive up front. | Clusters tightly by OS and version family. |
| MSS | The largest segment the link says it will carry. | About 1460 on a direct ethernet path. A lower value means a tunnel trimmed it. |
| Window scale | A shift value that multiplies the window for fast links. | Each stack favours a small, predictable set of values. |
| TCP option order | The sequence in which the OS lists its handshake options. | The strongest tell. Every stack writes its options in its own order. |
The JA4T format simply lines a few of those up into one readable string: the window size, then the option kinds in order, then the MSS, then the window scale. Something like 64240_2-4-8-1-3_1460_7. That little string is not a name or an account. It is a description of how a network stack talks, and it is remarkably consistent for a given operating system family while being awkward to forge from inside a browser.
That last part is the whole point. Your browser can rewrite what it says. It cannot easily rewrite how your kernel speaks.
Active vs Passive: Two Ways to Read an OS
There are two schools of operating system fingerprinting, and the difference matters for your privacy.
Active OS fingerprinting is the loud one. A tool fires specially crafted packets at a machine and studies how it replies. This is the territory of Nmap OS detection, of Xprobe2 with its fuzzy ICMP probes, and of SinFP. It is powerful and detailed, but it is noisy. It shows up in firewall logs and trips intrusion-detection systems, because it has to send traffic to learn anything.
Passive OS fingerprinting never sends a thing. It just watches packets that were already flying past. This is the lineage of p0f, and now of JA4T. No probe, no footprint, no entry in a log that says "someone scanned you."
| Aspect | Active (Nmap, Xprobe2, SinFP) | Passive (p0f, JA4T) |
|---|---|---|
| How it works | Sends crafted probes, measures the replies. | Listens to the SYN you already sent. |
| Footprint | Noisy. Lands in logs and IDS alerts. | Silent. Leaves no trace. |
| Needs JavaScript | No | No |
| Where you meet it | Security recon, asset scanning. | WAFs, anti-bot, ad-tech, and this page. |
For someone trying to understand their own exposure, passive is the one to worry about. It is the version a website or an anti-fraud system can run on you, silently, during a normal page load. Tools like Satori, NetworkMiner and ettercap have automated passive fingerprinting for years. The novelty now is seeing it pointed back at you, in plain language, the moment you open a page.
From p0f to JA4T: a Short History
Passive OS fingerprinting is not new. It goes back to p0f, written by Michał Zalewski, which sat quietly on a network, grabbed the first SYN of each connection, and named the operating system behind it. For two decades that was the reference.
The web changed underneath it. Encryption went everywhere, IP addresses stopped meaning much, and defenders needed signals that survived a proxy. So the idea was modernised. FoxIO, the team behind the JA4+ suite, published JA4T as a clean, shareable way to fingerprint the TCP client from that same first packet, sitting alongside JA4 for the TLS handshake and JA4H for HTTP. FoxIO's own pitch is blunt: a good TCP fingerprint can quietly account for the large majority of internet scan traffic before it ever reaches an application.
Today the technique lives inside the tools that decide whether you look human: network monitors like Zeek, the big web application firewalls, and the bot-detection layers in front of banks, shops and ticket sites. JA4T does for the raw TCP handshake what JA4 does for the TLS handshake and JA4H does for HTTP. The TLS side is covered separately in TLS Fingerprinting. This piece stays at the layer underneath it, the raw TCP packet.
The Tell: When Your Connection and Your Browser Disagree
A fingerprint on its own is just trivia. The interesting moment is the comparison.
Your browser announces an operating system in its User-Agent and Client Hints. Your connection reveals one through its TCP fingerprint. A defender lines the two up and asks a single question: do they agree?
The classic giveaway
The claim: the browser says Chrome on Windows. The wire: the SYN packet looks like Linux. The read: a layer sits between you and the server, rewriting the label but not the packet. Very often that is a plain VPN or proxy, which is completely legitimate. It only looks like a real lie when the wire reveals an OS a proxy almost never runs, like Apple or Windows, because then it is your true OS leaking past the mask rather than a server in the middle.
This is why TCP fingerprinting is so prized for bot detection. A script can set any User-Agent it likes in a fraction of a second. Making the kernel underneath actually be the operating system it claims is a different kind of work. The label is cheap. The accent is expensive.
It pairs naturally with the browser-side checks covered in Device Integrity. That article looks at the lie from inside the browser, where a spoofed User-Agent collides with navigator properties. TCP fingerprinting catches the same lie from outside, on the wire, where the browser has no say at all. Two independent witnesses to the same story are much harder to fool than one.
Why It's Hard to Fake (and Where It Breaks)
The strength of this signal is that it is tied to the operating system kernel. A browser extension, a User-Agent switcher, even most "privacy" tweaks live far above the network stack and cannot reach down to change how SYN packets are built. So the casual mask, the one-click "make me look like an iPhone," gets caught instantly. The wire keeps telling the truth.
Now the honest part, because pretending otherwise would be a disservice. This is not unbeatable.
People who do this for a living can rewrite the network stack to match the operating system they are claiming. Modern antidetect operators do exactly that, tuning the TTL, the window, and the option order to match the profile they wear. Searching for how to defeat OS fingerprinting turns up plenty of guidance, some of it decades old, because the cat-and-mouse game is decades old. The point is not that the accent is impossible to fake. The point is that faking it convincingly takes real effort at a layer most people never touch, which is precisely why it filters out the easy disguises while the careful ones slip through. No single signal is a lie detector. A stack of them, read together, is a great deal harder to beat.
What the packet.guru Scan Actually Reads
Most writing about TCP fingerprinting is aimed at defenders: how to run it on other people. The Privacy & Trust scan turns the camera around and shows you what your own connection gives away, in language meant for a human rather than a firewall log.
A few principles guide how it reads your handshake, and they are worth stating plainly:
- It only resolves an operating system family, not a person. The honest ceiling of passive TCP fingerprinting is roughly three kernel families: Windows, Apple, and Linux. macOS and iOS share Apple's XNU kernel, and desktop Linux and Android share the Linux kernel, so the network stack cannot reliably tell those siblings apart. Anyone claiming a passive SYN reveals your exact device down to the model is overselling it. The scan does not pretend to.
- When it is not sure, it says nothing. An unrecognised or ambiguous fingerprint produces no verdict at all, never a guess. That rule is deliberate. A wrong label here would mean accusing a real, honest browser of lying, which is the worst possible failure for a tool like this.
- It weighs trust, not privacy. If the connection's OS matches what the browser claims, that is a clean result. If they disagree because a real OS leaked past a mask, the cost lands on trust, on how genuine you look to a website, not on the privacy of your browsing. Hiding is never the crime. That distinction comes next.
- Tor is treated as protection, not a red flag. When you connect through Tor, the exit relay rebuilds the connection, so the packet the server sees belongs to the relay, not to you. Your real operating system is simply hidden. The scan calls that what it is, a privacy win, and leaves it green.
You will find this as the TCP / OS card on the dashboard. It reads the handshake passively, the same way an anti-fraud system would, and tells you whether your connection and your browser are telling the same story. To see the operating system your browser openly claims in the first place, the HTTP Headers Checker shows the raw User-Agent it sends.
Hiding Versus Faking
Here is the distinction that most fingerprinting tools get wrong, and the one packet.guru is built around.
Hiding your operating system is a perfectly legitimate thing to do. Route your traffic through a VPN, a proxy, or Tor and, in most cases, the destination ends up reading the exit point's network stack instead of yours. Not always. A transparent proxy or plain home NAT can let your real fingerprint pass straight through, and a poorly built tunnel can leak parts of it. Either way, masking your OS is the system working as intended, and it should not be treated as guilt. This is the same philosophy that runs through the bigger platform rebuild: masking is not abuse.
Faking is the other thing. Trying to pass your machine off as a different machine, telling a website you are an iPhone while a Windows kernel hums underneath, is not hiding. It is impersonation, and it is exactly the move at the heart of antidetect browsers and large-scale fake-account operations. A passive OS fingerprint is one of the cleaner ways to catch that specific lie, because the costume is worn at the browser layer while the truth keeps speaking one layer down.
The practical takeaway is the same one this whole topic keeps circling back to. The safest profile is not the most heavily disguised one. It is the most consistent one. A real Mac that looks like a real Mac, behind a VPN if you like, raises no contradictions. A desktop wearing a phone's User-Agent raises several, and contradictions are what get you buried under endless CAPTCHAs. The same logic governs the geography signals in Regional Integrity: one mismatch is a normal human story, several at once are a pattern.
FAQ
Q: Can a website really tell my operating system without JavaScript?
Yes. The operating system is read from the TCP handshake itself, which happens before any script loads and even before the encrypted part of the connection begins. Disabling JavaScript does nothing to it. This is the defining trait of passive fingerprinting: there is nothing on the page to block.
Q: Can a VPN change my TCP fingerprint?
It depends on how the VPN works. A full system VPN routes packets through its own stack, so the server tends to see the VPN endpoint's operating system rather than yours, which is why the fingerprint can read as Linux on a hosted server. A simple transparent proxy or a home router doing plain NAT may pass more of your real stack through. Either way, a VPN usually changes the fingerprint rather than perfectly matching the OS your browser claims, and that gap is what gets noticed.
Q: Why does it only report three operating systems?
Because three is the honest limit of passive TCP fingerprinting. macOS and iOS share one kernel, and desktop Linux and Android share another, so their network stacks are not reliably distinguishable from the outside. Splitting them further would mean guessing, and guessing here means false accusations.
Q: How do I see my own TCP fingerprint?
Run the Privacy & Trust scan and look at the TCP / OS card. It shows the operating system your connection implies, whether it matches the one your browser claims, and what that means for how trustworthy you look to an anti-fraud system.
The Bottom Line
You spend a lot of energy deciding what your browser says about you. The first packet of every connection has already spoken, quietly, before any of that, and it is much harder to talk over.
That is not a reason for alarm. It is a reason to aim for consistency instead of disguise. The truth keeps speaking through the wire whether you want it to or not, so the winning move is to make sure the rest of your setup is telling the same story.