Chrome Hard Reload Shortcut: Clear Cache Fast (2026)

The Chrome hard reload shortcut is Ctrl+Shift+R on Windows and Linux and Cmd+Shift+R on Mac. That is the answer. What follows is the part that actually saves you an afternoon: the three different reload strengths Chrome exposes, why the strongest one still fails on sites with a service worker, and how to stop reaching for the shortcut at all while you develop.

If you have ever changed a stylesheet, refreshed, seen nothing change, refreshed harder, and then stared at the file wondering whether you saved it — this is the article that explains what was actually happening.

Every Reload Shortcut, By Platform

Chrome exposes more reload variants than most people realize.

Normal reload — Ctrl+R on Windows and Linux, Cmd+R on Mac. F5 also works on Windows. Chrome revalidates the main document but happily serves subresources from the local HTTP cache if their cache headers say they are still fresh.

Hard reload — Ctrl+Shift+R on Windows and Linux, Cmd+Shift+R on Mac. Shift+F5 and Ctrl+F5 are equivalent on Windows. The request goes out with cache-bypassing headers, and Chrome refuses to use cached copies of the page and its subresources for that navigation.

Empty cache and hard reload — no default key binding. Open DevTools, then right-click (or click and hold) the reload button in the toolbar. A menu appears with three entries: Normal Reload, Hard Reload, and Empty Cache and Hard Reload. The third one deletes the cached entries for the current origin before performing the reload.

That third option only appears while DevTools is open. Without DevTools, right-clicking the reload button does nothing special. This trips people up constantly — they read about the option, right-click, see nothing, and conclude their Chrome is broken.

Reload all tabs — no built-in shortcut. Chrome does not ship one. A middle-click on a tab group header or an extension is the usual workaround.

The Chrome hard reload shortcut is one of a small set of bindings worth committing to muscle memory rather than looking up; the wider set is collected in chrome keyboard shortcuts developers, and Mac users can find every Cmd-key equivalent in the macOS Chrome shortcut guide.

What Each Reload Level Actually Does

The difference between the three levels is not "how hard Chrome tries." It is which caches get consulted.

Normal reload. Chrome re-requests the main HTML document, usually with a conditional request carrying an If-None-Match or If-Modified-Since header. The server may answer 304 Not Modified, in which case Chrome uses its cached copy. Subresources — scripts, stylesheets, images, fonts — are served straight from the HTTP cache if their max-age has not expired. This is why a normal reload can show you a page that is entirely stale below the HTML layer.

Hard reload. Chrome sends the navigation and all its subresource requests with cache-defeating headers, typically Cache-Control: no-cache and Pragma: no-cache. The server is forced to respond with the full body rather than a 304. Critically, this applies to resources referenced by the page you are reloading — but not to resources requested later by JavaScript after the page has loaded. A lazily loaded chunk fetched three seconds after page load can still come from cache.

Empty cache and hard reload. Chrome evicts the cached entries for the current origin, then performs a hard reload. Because the cache is empty, nothing can be served from it — including those late-arriving lazy chunks. This is the strongest reload Chrome offers through the UI.

The practical escalation ladder: normal reload for ordinary browsing, the Chrome hard reload shortcut when you suspect a stale asset, empty cache and hard reload when the hard reload did not fix it.

The Service Worker Problem: Why Hard Reload Sometimes Does Nothing

Here is the single most common reason a developer's Chrome hard reload shortcut appears to be broken.

A service worker sits between the page and the network. When the page requests a file, the service worker's fetch handler runs first. If that handler answers from the Cache Storage API, the request never reaches the network — and cache-bypassing HTTP headers are irrelevant, because there is no HTTP request to attach them to.

So on any site running a service worker with a cache-first strategy — most progressive web apps, most modern framework starter templates, a growing share of production sites — a hard reload can return the exact same stale files it returned before. The shortcut worked perfectly. It just cannot reach past the service worker.

The fix, in order of increasing severity:

1. DevTools, Application panel, Service Workers, tick "Bypass for network". Every request skips the service worker while DevTools is open. This is the setting to leave on during development.
2. Click "Update" next to the registered worker, then reload. Forces the browser to fetch and install the current worker script.
3. Click "Unregister", then reload. The page loads with no worker at all, then registers a fresh one.
4. Application panel, Storage, Clear site data. Nuclear option. Wipes Cache Storage, service worker registration, local storage, IndexedDB, and cookies for the origin.

If you ever find yourself pressing the Chrome hard reload shortcut five times in a row, stop and open the Application panel. Five hard reloads have never fixed anything that one did not.

Stop Reloading Hard: The Disable Cache Checkbox

The best hard reload is the one you never have to press. Open DevTools, go to Settings (the gear icon or F1), then Preferences, then the Network section, and tick Disable cache (while DevTools is open).

With that on, every request from that tab bypasses the HTTP cache for as long as DevTools stays open. A plain Ctrl+R behaves like a hard reload. The Chrome hard reload shortcut becomes redundant during development, which is exactly where you want to be.

Two caveats worth knowing:

• The setting is per tab and only while DevTools is open. Close DevTools and the cache returns immediately. This is a feature — it means you can test cache behavior by simply closing the panel.
• It does not bypass service workers. Pair it with "Bypass for network" in the Application panel for a genuinely clean development environment.

Setting both of these on your development profile once removes the majority of "why is my change not showing" incidents. It belongs in the same category as disabling autofill on a test profile — a two-second configuration that pays back for years. The wider DevTools configuration set is covered in chrome devtools tips and tricks.

Hard Reload vs Clearing Browsing Data vs Incognito

Three different tools for three different problems, and they get confused constantly.

Hard reload targets the HTTP cache for one page load. Cookies, storage, and login state survive. Fast, surgical, and reversible in the sense that nothing was destroyed except cache entries. Use it when you suspect a stale asset.

Empty cache and hard reload targets the HTTP cache for the current origin. Still leaves cookies and storage intact. Use it when a hard reload was not enough and you suspect a lazily loaded chunk or a long-lived asset.

Clear browsing data (Ctrl+Shift+Delete) targets everything you select, across all sites or a time range. Cookies go. Logins go. It is a blunt instrument and using it to debug a single stale stylesheet means logging back into everything afterward. Reach for it almost never.

Incognito gives you a fresh cache, fresh cookies, and no extensions by default. Nothing is cleared — a separate profile context is created. This is the fastest way to answer "is this a caching problem or a code problem?" If the page works correctly in incognito and is broken in your normal window, you have a state problem, not a code problem. If it is broken in both, stop blaming the cache.

A fourth option that deserves more use: a second Chrome profile dedicated to testing. Clean extension list, clean cookies, clean cache, and you can keep it open beside your main window. Profiles cost one click and remove an entire category of confusing state.

The Hard Reload Shortcut on Other Browsers

Cross-browser work means knowing more than one binding.

Microsoft Edge — identical to Chrome. Ctrl+Shift+R and Cmd+Shift+R. Same reload button context menu with DevTools open. Same Disable cache checkbox. Edge is Chromium, so essentially everything in this article transfers directly.

Firefox — Ctrl+Shift+R on Windows and Linux, Cmd+Shift+R on Mac. Firefox DevTools has its own "Disable HTTP Cache" checkbox in the Network panel settings, which behaves the same way as the Chrome equivalent.

Safari — Cmd+Option+R performs a reload from origin. There is also a Develop menu item, "Disable Caches", which needs the Develop menu enabled in Settings first. Safari also treats Cmd+R differently depending on whether Web Inspector is attached.

Brave, Arc, Vivaldi, Opera — all Chromium, all Ctrl+Shift+R or Cmd+Shift+R. Arc hides some of the toolbar chrome, but the keyboard binding is unchanged.

Learning the Chromium binding covers most of the browsers most people use. Safari is the one exception worth memorizing separately, and it is exactly the browser where a stale cache is most likely to be mistaken for a rendering bug.

When Hard Reload Is Not the Right Tool

Some stale-content problems look like cache problems and are not. Recognizing them saves the most time of all.

A CDN is serving the stale copy. Your browser cache is clean, the request goes to the network, and the CDN edge returns the old file because its own TTL has not expired. No amount of hard reloading fixes this. Check the response headers for an Age or X-Cache header, and purge from the CDN dashboard.

The build did not actually run. Frighteningly common. Check the build output timestamp before blaming the browser. If the file on disk is old, the browser is doing its job perfectly.

A proxy or corporate middlebox is caching. Enterprise networks sometimes cache aggressively on the way out. Test on a different network or a phone hotspot to isolate it.

The page is server-side rendered and the server is caching. A full-page cache on the origin returns identical HTML no matter what headers the browser sends. Look for a cache header in the response, or hit the origin directly bypassing the CDN.

Content hashing is doing its job and you are looking at the wrong file. Modern build tools fingerprint filenames. If you see app.a1b2c3.js in the network panel and your new build produced app.d4e5f6.js, the HTML is stale, not the JavaScript. Focus on why the document is cached rather than the asset.

The diagnostic move for all five: open the Network panel, disable cache, reload, and read the Size column. A value of "(disk cache)" or "(memory cache)" means the browser served it locally. An actual byte count means it came from the network — and if the network copy is stale, the problem is upstream of Chrome entirely.

Building the Reload Reflex Into a Faster Loop

Reloading is a symptom of a workflow, and the workflow is worth tuning.

Run a dev server with hot module replacement. Vite, Next.js, and every modern framework tool ship it. Changes appear without any reload at all. When HMR is working correctly you should press the Chrome hard reload shortcut roughly never during a normal day.

Keep DevTools docked and open. Both cache-defeating settings only apply while it is open, and having the Network panel visible turns cache questions into two-second observations instead of guessing games.

Learn the DevTools command palette. Ctrl+Shift+P inside DevTools opens a searchable command list. Typing "cache" surfaces the disable-cache toggle directly, and typing "reload" surfaces the reload variants. Faster than navigating the settings tree.

Bind the actions you repeat. Chrome lets you assign extension commands at chrome://extensions/shortcuts. Reload itself is not bindable there, but the surrounding actions in a debugging loop often are — including copying the address of the page you are testing. Reproduction steps, staging links, and preview deploy addresses get pasted into tickets and chat dozens of times a day, and the address bar round trip is the same three-keystroke tax every time. The Ctrl+Shift+C extension reduces it to one keystroke, with clipboard permission only and no network calls or data collection, which keeps it out of the way of the network panel you are staring at.

Write down the reload ladder once. Normal, hard, empty cache and hard, bypass service worker, clear site data, incognito, different profile, check the CDN. Working the ladder in order takes ninety seconds and beats randomly mashing shortcuts every time. If you want the full set of bindings around this one, chrome shortcuts cheat sheet collects them.

Frequently Asked Questions

What is the Chrome hard reload shortcut? Ctrl+Shift+R on Windows and Linux, Cmd+Shift+R on Mac. On Windows, Shift+F5 and Ctrl+F5 do the same thing if you prefer function keys. All of them send the navigation with cache-bypassing headers so the server must return fresh copies rather than allowing a 304.

What is the difference between reload and hard reload? A normal reload lets Chrome serve subresources from the local HTTP cache when their cache headers still consider them fresh, and it may accept a 304 for the document itself. A hard reload forbids both, forcing full responses for the page and the resources it references during load.

What does empty cache and hard reload do that Ctrl+Shift+R does not? It deletes the cached entries for the current origin before reloading, instead of merely bypassing them for one navigation. That matters for resources fetched by JavaScript after page load, which a plain hard reload does not cover. Find it by right-clicking the reload button with DevTools open.

Why does a hard reload not pick up my JavaScript changes? Almost always a service worker. It intercepts fetch requests and answers from Cache Storage before the network is consulted, so cache-bypassing HTTP headers never come into play. Tick "Bypass for network" in the DevTools Application panel, or unregister the worker.

How do I make every reload a hard reload while developing? Open DevTools, Settings, Preferences, Network, and tick "Disable cache (while DevTools is open)". Every request from that tab bypasses the HTTP cache as long as the panel stays open. Pair it with the service worker bypass for a fully clean loop.

Does a hard reload clear cookies or log me out? No. It affects the HTTP cache only. Cookies, local storage, session storage, and IndexedDB are untouched, so you stay logged in. If you need those cleared, use Clear site data in the Application panel, which is a much heavier action.

Is the hard reload shortcut the same in Edge, Firefox, and Safari? Edge and Firefox use the same Ctrl+Shift+R and Cmd+Shift+R. Safari uses Cmd+Option+R for reload from origin, and offers a Disable Caches item in the Develop menu once that menu is enabled in Settings.

Reload Less, Ship Faster

The Chrome hard reload shortcut is Ctrl+Shift+R or Cmd+Shift+R, and it solves exactly one class of problem: a stale entry in your local HTTP cache. Learn the escalation ladder past it — empty cache and hard reload, service worker bypass, incognito, clean profile, CDN — and you will stop losing afternoons to caching mysteries. Then set Disable cache once on your development profile so the shortcut becomes something you barely need. While you are tuning that loop, Ctrl+Shift+C removes the other repeated tax in a debugging session — copying the address you are testing into a ticket or a chat thread — in one keystroke, free, clipboard permission only, zero data collection. Install it and keep your hands where the work is.