JavaScript location.reload(true): What It Used to Do, Why It No Longer Works, and Modern Alternatives

TL;DR

• location.reload(true) once told the browser to skip cache and do a hard‑reload.
• The boolean argument was officially deprecated in HTML 5.1 and is ignored by every current browser.
• Today you should call location.reload() with no arguments, or use other cache‑busting techniques if you need a fresh copy of the resource.

Anatomy of location.reload

window.location.reload(optionalForceGet);

Historically this API came from DOM Level 0 (a Netscape/IE era relic). A forced reload was handy in dial‑up times to guarantee users saw the newest HTML.

Why Was It Removed?

1. Undefined behavior: Browsers interpreted “force” differently (some purged memory cache, others bypassed both disk and proxy caches).
2. Same outcome via UI: Users already have Ctrl + F5 / Cmd + Shift + R.
3. Spec clean‑up: HTML 5.1 simplified the interface:
   

   If the forceReload argument is provided, user agents must ignore it.
   ‑ WHATWG HTML Living Standard

Current Cross‑Browser Behavior

Bottom line: The boolean flag is a no‑op everywhere.

What If I Need a Hard Reload from Code?

Because the official API no longer exposes a “cache‑bypass” switch, you must achieve it indirectly.

Query‑string cache busting

const url = new URL(location.href);
url.searchParams.set('_cb', Date.now());
location.replace(url);      // avoids extra history entry

Whenever the timestamp changes, the browser treats it as a new resource and bypasses the cache.

Manual cache headers

If you control the server, set proper HTTP headers instead:

Cache-Control: no-store
Pragma: no-cache           /* for ancient proxies */

Then a normal location.reload() is enough.

Service‑Worker environments

If your site is PWA‑enabled, you can instruct the service worker to flush its cache and claim clients before calling clients.reload():

// inside service‑worker.js
self.addEventListener('message', event => {
  if (event.data === 'force-update') {
    caches.keys().then(keys => Promise.all(keys.map(caches.delete)))
      .then(() => self.skipWaiting());
  }
});

Bookmarklets and the javascript: URL Scheme

Many tutorials from the early 2000s show:

<a href="javascript:location.reload(true)">Hard Refresh</a>

Because the argument no longer matters, you can simplify to:

<a href="javascript:location.reload()">Refresh</a>

However, bookmarklets are a fading pattern—modern Content‑Security‑Policy headers often block javascript: URLs. Prefer a real <button> with an onclick handler:

<button id="refresh">Refresh</button>

<script>
document.getElementById('refresh').addEventListener('click', () => location.reload());
</script>

FAQ

Q: Will using location.reload(true) hurt anything?
A: No, it just behaves exactly like location.reload()—but it’s misleading code. Remove the argument for clarity.

Q: Is there a standards‑based way to force reload?
A: Not directly. The spec intentionally leaves cache control to HTTP headers and Service‑Workers.

Q: Does location.reload() always hit the network?
A: Only if the cached resource has expired or if server’s validation (ETag/Last‑Modified) fails. Otherwise the browser serves it from cache.

Migration Checklist

1. Search your codebase for location.reload( and remove any arguments.
2. Decide if you truly need to bypass cache.
3. Implement one of the alternatives (query‑string, cache headers, or SW update flow).
4. Document the change in your project’s coding guidelines.

Conclusion

javascript:location.reload(true) is a vestige of an earlier web.
Use plain location.reload() for a vanilla refresh, and fall back on modern, explicit cache‑busting strategies when a “hard refresh” is truly required.

Happy coding!