Threat Model
Published
No. And the useful part of that answer is not the word, it is the reason — because the reason tells you which of the things sold as alternatives are worth switching on, which are theatre, and which will cost you more in support tickets than the code was worth.
Why the answer is structural
Developer tools are browser interface. They live on the far side of the boundary that separates the browser from the pages it renders, next to the address bar and the bookmark menu — and that boundary exists specifically so a hostile page cannot take control of the user’s software. There is no API to close a panel, no permission to request, no clever trick pending discovery. A page asking to disable DevTools is asking for the one thing the web’s security model is built to refuse.
The same boundary makes View Source unreachable. The view-source: scheme, the browser menu and the network panel all read bytes the browser already holds; your code is not consulted. Neither is it consulted when someone runs curl against your CDN, opens the file in a proxy, or reads it out of the disk cache. That is a lot of doors, and page JavaScript is standing in none of the doorways.
What a script can do is notice side effects. A keystroke that reaches the page can be swallowed. A pause in execution long enough to suggest a debugger can be measured. Both are observations after the fact, not prevention, and both have a false-positive rate.
The classics, and what they cost
Blocking right-click. Twenty years old, still shipped, still useless. It stops one route out of eight to bytes the browser has already downloaded. What it reliably does is break copy and paste, open-in-new-tab, spell-check, translation and the context menus assistive technology depends on — a real accessibility cost paid by every visitor to inconvenience none of the ones you were worried about.
Blocking keyboard shortcuts. Slightly more defensible, and there is an option for it: BlockDevToolsKeys intercepts the common combinations. Be clear-eyed about the scope — it works only when the page has keyboard focus, and only for the shortcuts. The browser menu is untouched, so is a bookmarklet, so is a second tab, and so is remote debugging. Treat it as a speed bump for the incurious.
Console banners and warnings. The "Stop! This is a browser feature intended for developers" message. It genuinely helps against social-engineering attacks that talk victims into pasting code into the console, which is a real and current attack. It does nothing about someone reading your source, and it was never meant to.
Infinite debugger loops. The aggressive version, and the one most likely to hurt you. Anyone who wants past it right-clicks the line and chooses never pause here; meanwhile a mis-timed check on a slow phone can wedge a paying customer’s session.
What the runtime options actually do
The protection engine ships several controls in this area, and they are worth understanding as a set rather than as a checkbox to tick.
DebugProtection adds debugger-trigger friction and timing checks. DebugProtectionIntervalMilliseconds sets the cadence, accepting 0 for no periodic probes or 100 to 60,000 milliseconds. Frequent probing costs battery and raises false positives; occasional probing is the sane default.DisableConsoleOutput suppresses common console methods in protected browser output. Useful for stopping your own diagnostics from narrating your logic to a reader, less useful against an attacker who sets breakpoints instead.SelfDefending wraps output in integrity checks that fail when the generated function body changes. This is the one with real teeth against casual analysis: run the file through a beautifier and the check trips, so the attacker’s first instinct — reformat it to read it — costs them time.AntiMonkeyPatching snapshots selected browser APIs and detects replacements made after startup, with an optional same-origin clean realm to catch APIs already patched before your code ran. This targets tampering rather than reading, which is a different and often more important threat.
Every one of them routes failure through the same runtime defense action: throw, blank, redirect, reload, callback or degrade. The choice matters more than the detection. degrade sets a flag and dispatches an event so your application can disable a sensitive feature or require step-up authentication; callback reports and returns. Both let a false positive pass without destroying a real session. Blanking the page does not, and every timing check has a false-positive rate on hardware you will never see. The full option list is in the runtime defense documentation.
The three things that genuinely work
Do not publish source maps. This is first because it is the one people get wrong while doing everything else right. A published .map hands over your original files, original names and original comments — every protection option in the product, undone by one build setting. Your source maps are publishing your source code covers how to check, and a build-time audit is a one-line CI addition.
Do not ship what must not be read. An API key, a pricing formula that decides what a customer is charged, an entitlement check that grants access. Anything whose exposure is unacceptable does not belong in a browser at any obfuscation strength, because the person you are worried about will read it eventually. Move authority to the server; keep the client copy for responsiveness.
Make the rest expensive. This is where protection earns its keep and where it is honestly measured: not "can this be reversed" — anything running in a browser can — but "how many hours does a competent reader need". Name protection, string protection and control-flow work turn an afternoon of reading into a week, and VM protection on the two or three functions that carry real value turns a week into something most people abandon. Is JavaScript obfuscation reversible? takes the question seriously rather than selling past it.
A workable position
Ship no source maps. Keep secrets and authority server-side. Protect the code that has to be public, with the strongest settings on the small part that matters. Switch on SelfDefending, because reformatting is the attacker’s first move. Add DebugProtection at a modest interval with a degrade or callback response if your risk justifies it, and send the event somewhere you will read it — a signal that someone is analysing your checkout page is worth more than a blanked screen. Skip the right-click blocker entirely.
Then stop measuring success by whether DevTools opens. It will open. Measure it by what a reader can do with what they find, and that is a number you control.
Frequently asked questions
Can JavaScript disable the browser's developer tools?
No. Developer tools are part of the browser's own interface, outside the page's security boundary, and no API exists for a page to close or block them. A script can only observe side effects - a keystroke it happens to receive, or a timing anomaly consistent with a paused debugger - and react. It can never prevent the tools from opening.
Does blocking right-click protect my source code?
No. The context menu is one of many routes to the same bytes: the browser menu, a keyboard shortcut, the view-source scheme, the network tab, curl, or a proxy. Blocking it stops nobody who intended to look, and it breaks copy, paste, open-in-new-tab, spell-check and assistive technology for everybody who did not.
What does the debug protection option actually do?
It adds debugger-trigger friction and timing checks to the protected output. A paused execution context is measurable, so the code can notice and route the event through your chosen response. DebugProtectionIntervalMilliseconds sets the probe cadence, accepting 0 for no periodic probes or a value from 100 to 60,000 milliseconds. It raises the annoyance of casual stepping; it does not stop analysis.
Will debugger detection cause false positives for real users?
It can. Timing checks measure elapsed time, and a slow device, a heavily loaded tab, a background throttle or a browser extension can produce the same signal as a paused debugger. Choose the response accordingly: degrade or a callback keeps you informed without destroying a legitimate session, while throwing or blanking turns a false positive into a support ticket.
What actually reduces what someone learns from my JavaScript?
Three things. Do not publish source maps. Do not put secrets or authorisation decisions in the client at all. And make what remains expensive to read through name, string and control-flow protection, with VM protection reserved for the few functions that carry real value. Everything else is friction, and friction has a support cost.
Related reading