How pages guess that DevTools is open: the window-size gap, debugger-statement timing and console getters, why each misfires, and why it is a weak signal.
Some pages go oddly quiet the moment you press F12: the content blanks out, the tab freezes, or a "debugger paused" bar appears and will not go away. That is not magic. A script on the page is guessing that DevTools is open, using side effects the browser cannot hide from page JavaScript. This guide covers the three classic techniques, how each one fails, and why none of them is a reliable signal on its own.
Key Takeaways
- No browser tells a page "DevTools is open". Every detector is a heuristic that infers it from a side effect: a changed window size, a paused script, or a console call that behaves differently.
- The window-size gap compares
outerWidthwithinnerWidth(and the heights). Docked DevTools eats viewport space, so the gap grows. Undocked DevTools leaves the gap unchanged. - The
debuggerstatement pauses execution only while DevTools is open, so a script that times the pause, or fires the statement in a loop, can notice or punish an open panel. That loop is why some pages freeze. - Console getters fire when the console formats an object. It is the same family of trick as the CDP serialization leak, and its behaviour varies by browser version.
- It is a weak signal. Developers, support staff and curious users open DevTools legitimately, and zoom or side panels trigger false positives, so serious systems treat it as one low-weight input.
Why Sites Look for an Open DevTools
The goal is almost never to catch the person reading the page. Typical motives are:
- Anti-scraping. Someone inspecting network requests or the DOM is often the first step toward scraping, so a site may raise a risk score.
- Protecting client-side code. Paywall logic, obfuscated scripts and ad-verification code are easier to study with a debugger attached.
- Fraud and abuse scoring. An open inspector is one more weak input next to the stronger ones in a bot detection stack.
Note the scope: this guide is about a human opening DevTools by hand. Automation frameworks that drive the browser through the protocol behind DevTools are a different problem, covered in detecting CDP automation and headless browser detection.
Technique 1: The Window-Size Gap
The browser exposes two sizes. window.outerWidth is the width of the whole browser window including toolbars and side panels, while window.innerWidth is the width of the page viewport. Normally the widths differ by only a few pixels of window border, and the heights by the tab strip and toolbar, which is why detectors set the threshold well above that. Dock DevTools to the side or bottom and the viewport shrinks while the outer window stays the same, so the gap jumps by hundreds of pixels.
const threshold = 160; // px
const widthGap = window.outerWidth - window.innerWidth > threshold;
const heightGap = window.outerHeight - window.innerHeight > threshold;
const looksOpen = widthGap || heightGap;
It is cheap, passive and needs no permission, which is why it is the most common check. It also fails in predictable ways:
- Undocked DevTools opens in its own window, so the page's viewport does not change and nothing is detected.
- Side panels and sidebars in the browser (reading lists, AI assistants, vertical tab strips) also shrink the viewport and can look like a docked inspector.
- Zoom and display scaling change how the two values relate on some platforms, producing a gap with no DevTools at all.
- Mobile and embedded views often report odd or equal values, so the check is meaningless there.
The same two values also feed the screen and window checks in screen resolution fingerprinting.
Technique 2: The debugger Statement
The debugger statement invokes whatever debugging facility is available and does nothing if there is none. With DevTools closed it is a no-op that costs microseconds. With DevTools open (and breakpoints active) execution stops at that line until the user resumes.
That gives a page two uses. The first is timing: take a timestamp, run debugger, take another, and treat a pause of more than a few tens of milliseconds as "a debugger is attached".
const t0 = performance.now();
debugger;
const paused = performance.now() - t0 > 100; // human-scale pause
The second is a trap: call debugger repeatedly from a timer or a loop, so every time you resume it pauses again. This is the reason a page can seem to freeze or keep reopening the Sources panel when DevTools is open. Browsers let you deactivate breakpoints or skip a script, so it is an annoyance rather than a barrier, and a user who merely wanted to read the console gets a worse page for it.
Failure modes: a paused tab can be a sleeping laptop, a heavily loaded device or a background-throttled tab, all of which stretch the timing; and with breakpoints deactivated the statement is again a no-op.
Technique 3: Console Getters
When DevTools is open, logging an object makes the console build a preview of it. A page can log an object whose property is a getter and watch whether the getter runs.
let opened = false;
const probe = new Error();
Object.defineProperty(probe, "stack", {
get() { opened = true; return ""; }
});
console.log(probe);
Whether the getter fires depends on the browser, its version and which console panel is showing, and engines change this behaviour from time to time, so a check that worked last year may be silent now. The related Chromium mechanism, where an attached automation client makes every console.* call serialize its arguments, is explained in the CDP detection guide; the point to keep here is that a getter firing can mean "a human opened the console" or "a protocol client is attached", and the page cannot tell which.
Why It Is a Weak Signal
Every method above is a guess, and each guess has an innocent explanation. A web developer, a QA tester, a journalist checking a claim and a user following a support article all open DevTools, and a site that blocks them loses real customers. Meanwhile anyone determined to inspect a page can undock the panel or deactivate breakpoints, so the checks are heuristic and easy to sidestep. That is why they are used as one low-weight feature next to stronger evidence such as behavioural signals, never as a verdict on their own.
What BrowserInsight's Check Does
The fingerprint check shows a DevTools "opened" or "closed" flag among the browser details. It uses only the window-size gap with a 160 px threshold, so it behaves exactly as described above:
- Docked DevTools (side or bottom) is caught, because the viewport shrinks by more than 160 px.
- Undocked DevTools is not caught.
- A large browser side panel can trip it even when DevTools is closed.
The bot detection page lists a "Developer Tools Detection" row built on the same 160 px gap, rated low severity. When the gap is found it also runs a console-getter probe, but that probe never decides the result on its own. A separate "Mobile Emulation Detection" row looks for DevTools device mode: a mobile User-Agent on a desktop platform, or a browser window whose size does not match the reported phone screen.
Neither check uses the debugger statement, so BrowserInsight never pauses your page. Open the tool with DevTools docked, then undocked, and watch the flag change: it shows what a page can infer, not proof of anything.
FAQ
Can a website really see that I opened DevTools?
Not directly. It can only infer it from side effects such as a changed viewport size or a paused script, and the inference is often wrong.
Why does a page freeze when I open DevTools?
Usually a script is calling debugger in a loop, so each resume pauses it again. Deactivating breakpoints in the Sources panel stops the pauses.
Is detecting DevTools the same as detecting a bot?
No. This is about a human with the inspector open. Automation tools leave different traces, covered in headless browser detection.
Recommended Reading
- Detecting Chrome DevTools Protocol (CDP) Automation
- Bot Detection Techniques: How to Identify Bots and Crawlers
- Headless Browser Detection: How Selenium & Playwright Are Caught
- Screen Resolution Fingerprinting: What Your Display Size Reveals
- Behavioral Bot Detection: How Sites Spot Inhuman Mouse Moves
