window.location.reload(true) deprecated: location.reload & forceGet (javascript location reload)

javascript:location.reload(true), javascript location reload true, location.reload(true), window location reload, location reload, window.location.reload(true) deprecated, mdn location.reload true deprecated, mdn location.reload forceget deprecated true parameter, javascript location reload: no-arg reload(), legacy boolean ignored, Cache-Control, fetch cache.

Published

Updated

Read time 4 min read

Reviewed byDeepak Prasad

window.location.reload(true) deprecated: location.reload & forceGet (javascript location reload)

Huge query volume still lands on javascript:location.reload(true) (often a pasted fragment) and on spelled-out forms like javascript location reload true, location.reload(true), or window.location.reload(true) deprecated. MDN titles such as mdn location.reload forceget deprecated or mdn location.reload true deprecated describe the same history: an old boolean forceGet argument that browsers no longer standardize. Plain window location reload and location reload searches are the same Location.reload() API.

This page matches current specs: call reload() with no arguments. The legacy flag does not throw, but you should not depend on it for cache busting.

Environment: Node.js v20.18.2 with happy-dom where location is shown. HTTP/fetch samples are illustrative patterns, not a runnable server.


What reload() does today

Location.reload() reloads the active document like the user pressing refresh. In modern engines the method takes no parameters; reload.length is 0.

javascript
console.log(String(location.reload.length));

You should see one line logging 0.

Minimal in-page reload (no legacy argument):

html
<button type="button" onclick="location.reload()">Reload</button>

Passing true was an obsolete forceGet hint in older browsers (cache bypass). It is not part of the current Web IDL signature—see MDN’s note on the removed parameter—so mdn location.reload forceget deprecated true parameter style questions resolve to “ignore the boolean and control caching explicitly.”

Do not paste location.reload(true) into a live page just to experiment: many engines will start a navigation before any following console.log runs. In an isolated automated run, the legacy call does not throw; the recorded flag stays false, matching real browsers that ignore the argument instead of throwing.

Do not wrap reload(true) in try/catch expecting a signal: engines typically ignore the argument instead of throwing, so exceptions are the wrong tool. Use location.reload() and fix freshness elsewhere.


Why the true / forceGet flag went away

  • Interop: Implementations disagreed on whether true forced a network fetch; behavior was unreliable.
  • Explicit HTTP caching: Cache-Control, ETag, and validators give deterministic freshness without reloading the whole document.
  • Richer client caches: Service workers and fetch cache modes replace ad‑hoc “hard reload” flags.

Optional parameters in general are covered in JavaScript optional parameters; here the important point is the parameter itself was removed from the standard API shape.


Prefer these instead of “force reload”

HTTP response headers (server)

Tell the browser not to store sensitive HTML or APIs:

javascript
// Express-style handler (illustrative)
app.get("/latest", (req, res) => {
  res.setHeader("Cache-Control", "no-store");
  res.send({ ok: true });
});

Tune directives (no-cache, max-age, stale-while-revalidate, etc.) per resource instead of forcing a full navigation.

Cache-busting static asset URLs

Version query strings or filenames so CSS/JS updates bypass stale entries—often with a build id or timestamp, for example /app.css?v=20250611.

fetch without reloading the page

Use the Request cache option instead of inventing client request headers:

javascript
fetch("/api/state", { cache: "no-store" })
  .then((r) => r.json())
  .then((data) => {
    console.log(data);
  });

Service workers (advanced)

Inside a worker you can opt into network-first or cache: "reload" for specific requests; keep scopes narrow to avoid breaking offline behavior.

Full navigation when you really need it

Call location.reload() (no argument) or navigate with location.replace(url) when only a hard navigation solves the problem—accept that it reloads the whole document under the browser’s normal cache rules.


javascript: URLs vs location.reload

A search that looks like javascript:location.reload(true) mixes the deprecated javascript: URL scheme with location.reload. For in-page scripts, use a normal <script> or module and window.location.reload(); do not rely on javascript: links for navigation.


Summary

People still land on javascript location reload true and location.reload(true) because older tutorials promised a cache-busting boolean; modern browsers follow the current Location.reload() signature with no forceGet argument, so window.location.reload(true) deprecated searches should end with “call reload() and control freshness elsewhere.” Another frequent question is whether reload(true) throws so you can catch it—engines typically ignore the flag rather than throwing, which is why try/catch is the wrong signal for this behavior.

For real freshness, answer mdn location.reload forceget deprecated style intent with HTTP Cache-Control and validators, version your static asset URLs, use fetch cache modes for XHR-style data, and reserve location.reload() for cases where a full navigation is honestly what you need. Treat javascript: URL typos as a separate issue from window.location.reload().


References

Steve Alila

Specializes in web design, WordPress development, and data analysis, with proficiency in Python, JavaScript, and data extraction tools. Additionally, he excels in web API development, AI integration, …