Introduction

Redirecting with JavaScript means telling the browser to load a different URL. The right method depends on whether you want the old page to stay in browser history, whether the redirect should happen immediately, and whether you are in a traditional multi-page site or a client-side routed application.

The Three Main Options

The most common JavaScript choices are:

• 'window.location.href = url'
• 'window.location.assign(url)'
• 'window.location.replace(url)'

href and assign both navigate and keep the current page in history. replace navigates without keeping the current page in the history stack, so the user usually cannot click Back to return to the old page.

Basic Examples

window.location.href = "https://example.com";

window.location.assign("https://example.com");

window.location.replace("https://example.com");

If you are redirecting after login or after consuming a one-time token, replace is often the better choice because it prevents the user from navigating back to a stale intermediate page.

Delayed Redirects

If you need a delay:

setTimeout(() => {
  window.location.href = "https://example.com";
}, 3000);

This is useful for message pages such as "Saved successfully, redirecting..." but should be used carefully. Unnecessary delay usually feels slower, not smoother.

SPA Routing Is Different

In a React, Vue, Angular, or other client-side app, a full browser redirect is often the wrong tool for internal navigation. Use the framework router instead, so the app updates the URL without a hard page reload.

The plain window.location methods are still appropriate when:

• leaving the current origin
• forcing a full reload
• redirecting before the app is bootstrapped

JavaScript Versus Server Redirects

Client-side redirects are visible and happen after the browser loads the page. Server-side redirects are usually better when the route should never have been served to the client in the first place, such as permanent URL changes or authentication gates at the server edge.

So the real question is sometimes not "how do I redirect with JavaScript" but "should this be a client redirect or a server redirect."

That distinction matters for SEO, performance, and user experience. A client redirect can briefly show the old page or flash incorrect content before navigation. A server redirect avoids that, so if the redirect is unconditional and known before rendering, the server-side option is usually cleaner.

That is particularly true for auth gates and canonical URL fixes.

Another practical question is whether the redirect should be conditional on user state, feature flags, or form results. Once redirect logic becomes conditional, it is worth centralizing it in one place so different parts of the app do not compete and send the browser into loops or inconsistent flows.

That kind of centralization pays off quickly in larger front-end codebases.

It also makes redirect behavior easier to test.

That matters in real applications.

Frequently.

Common Pitfalls

• Using replace and then being surprised that the Back button does not return.
• Using full-page redirects for internal SPA navigation.
• Creating redirect loops with unconditional client-side logic.
• Delaying redirects without giving the user a meaningful reason.
• Relying on JavaScript redirects for things better handled on the server.

Summary

• Use href or assign when you want normal browser-history behavior.
• Use replace when the previous page should not remain in history.
• Use setTimeout only when a delayed redirect is genuinely useful.
• In SPAs, prefer the framework router for internal navigation.
• Consider whether the redirect should happen on the client at all.