How to Disable JavaScript in Chrome, and Why You Should Do It on Purpose

The fastest way to disable JavaScript in Chrome is the DevTools Command Menu: open DevTools, press Control+Shift+P (or Command+Shift+P on macOS), type javascript, and pick Disable JavaScript. It applies only while DevTools is open, which is exactly what you want.

That is the answer, and most pages stop there. The more useful question is why a developer would deliberately break a page they just built. Turning JavaScript off is one of the cheapest diagnostic tools available, and it answers questions that are genuinely awkward to answer any other way.

Table of contents

• The three ways to turn it off
• What a no-JavaScript reload actually tells you
• Debugging third-party scripts by elimination
• Testing what crawlers and assistive tech see
• When you should not test without JavaScript
• How this fits the rest of the stack
• FAQ

The three ways to turn it off

DevTools, per-tab, temporary. Open DevTools with F12, then the Command Menu with Control+Shift+P. Type javascript, select Disable JavaScript, press Enter. A warning icon appears next to Sources and in the address bar. Closing DevTools re-enables it automatically.

This is the one to use. It is scoped to the tab, it reverts on its own, and it cannot follow you home and break your banking site three days later.

Settings, global, persistent. Navigate to chrome://settings/content/javascript and select Don’t allow sites to use JavaScript. This applies everywhere until you change it back. Useful for a deliberate testing session, hazardous as a default.

Per-site rules. On the same settings page, the Not allowed to use JavaScript list takes specific origins. You can also reach it from the padlock icon in the address bar on any site — Site settings, then JavaScript, then Block. This is the right tool for a single misbehaving page you still need to load.

Note that DevTools disabling does not stop already-executing scripts; it prevents new execution. Reload the page after toggling it, or you are looking at a half-hydrated state that represents nothing real.

What a no-JavaScript reload actually tells you

Reload any page with scripts off and you see the server response as it arrives, before the client rewrites it. That single view answers several questions at once.

• Is the content server-rendered? If the page is blank, everything a crawler sees on first fetch is an empty shell. Search engines do execute JavaScript, but on a delayed second pass and with no guarantee of completeness.
• Does the navigation work? Links that are <div onclick> rather than <a href> vanish from the page’s link graph entirely. So does anything behind a router that never emitted a real URL.
• Do the forms submit? A form with a valid action and method posts without JavaScript. A form whose submit handler is the only path to the server does not.
• How much is layout and how much is script? If the layout collapses without JS, you are shipping CSS-in-JS or client-side layout logic that costs you on first paint.

None of this is an argument that pages should work fully without JavaScript. It is an argument that you should know exactly which parts do not, rather than finding out from a bug report.

Debugging third-party scripts by elimination

The single most practical use: a page is slow or broken and you suspect something you did not write. Analytics, chat widgets, consent managers, ad tags, session recorders, A/B testing snippets.

Disable JavaScript entirely and the page gets fast. That is not a fix, it is a confirmation that the problem is script-side. Now re-enable and narrow it: the Network panel’s request blocking lets you block a single URL pattern and reload, which isolates one vendor at a time.

DevTools -> Network -> right-click a request
  -> Block request URL      (blocks that exact URL)
  -> Block request domain   (blocks the whole vendor)

The blocked list lives under the Network conditions drawer
and persists across reloads until you clear it.

Third-party scripts are the most common cause of a Core Web Vitals regression that no code change explains. A marketing team added a tag last Tuesday. Nobody told engineering. Request blocking finds it in ninety seconds.

Testing what crawlers and assistive tech see

A no-JS reload is a rough approximation of the crawler’s first pass, and a genuinely useful sanity check before shipping a content site.

Pair it with View Page Source — which shows the raw HTML response, not the live DOM — and compare against the Elements panel, which shows the DOM after scripts have run. The delta between those two is the content that only exists client-side.

For anything content-driven — documentation, a blog, a marketing site, a product catalogue — that delta should be close to zero. If your product pages only exist after hydration, your indexing is at the mercy of a rendering queue you do not control.

Static output sidesteps the whole question. A site built to HTML at deploy time has no delta, because there is no second pass. That is the entire pitch for static generation on content-heavy routes, and it is why the static site docs start with build output rather than with runtime.

When you should not test without JavaScript

There is a failure mode where this becomes a religion. A dashboard, a design tool, a video editor, an interactive map — these are applications, and applications require a runtime. Auditing them for no-JS behaviour is wasted effort.

The useful line is roughly: content should survive without JavaScript, interaction may require it. A pricing page that renders nothing without scripts is a bug. A drag-and-drop workflow builder that renders nothing without scripts is a Tuesday.

The other thing worth saying plainly: users with JavaScript disabled are a rounding error. The reason to care is not that audience. It is that the same properties that make a page work without JavaScript — real URLs, server-rendered content, forms that post — make it faster, more crawlable, and more resilient when a CDN hiccups and one bundle fails to load.

How this fits the rest of the stack

Disabling JavaScript is a thirty-second diagnostic that catches slow third-party tags, invisible content, and navigation that only exists in a router’s memory. Use the DevTools toggle so it reverts on its own, reload before you draw conclusions, and treat the gap between View Source and the Elements panel as a number worth knowing. If you are weighing a static build against a rendered one for a content-heavy site and want to see how the two shake out on bandwidth and build minutes, the RunxBuild hosting calculator puts the line items next to each other.

Useful related references:

• Allow Chrome Through Your Firewall: Windows, macOS, and Linux
• “Server Can’t Be Found”: What That Browser Error Actually Means and How to Fix It on Chrome, Safari, and Firefox
• JavaScript Sleep: Why There Is No sleep() and What To Use Instead
• Services on RunxBuild

FAQ

How do I disable JavaScript in Chrome DevTools?

Open DevTools, press Control+Shift+P (Command+Shift+P on macOS) to open the Command Menu, type javascript, and select Disable JavaScript. It stays off only while DevTools is open.

Does disabling JavaScript in DevTools affect other tabs?

No. The DevTools toggle is scoped to the tab with DevTools open. The chrome://settings/content/javascript setting is global and persists until changed.

Why does the page still work after I disable JavaScript?

Scripts that already executed are not undone by the toggle — it only blocks new execution. Reload the page after disabling to see the true no-JavaScript state.

Will disabling JavaScript show me what Google sees?

It approximates the first crawl pass. Search engines do render JavaScript on a later pass, but that pass is queued and not guaranteed, so content that only appears after hydration is indexed less reliably.

How do I block just one third-party script instead of all JavaScript?

In the Network panel, right-click the request and choose Block request URL or Block request domain, then reload. This isolates a single vendor while the rest of the page runs normally.