Refresh general response

What it does

Refresh instructs the browser to reload the current page, or navigate to a different URL, after a specified delay. It's the HTTP-header equivalent of the HTML <meta http-equiv="refresh"> tag — same behavior, delivered via response header instead of embedded markup. Despite being widely supported, it's generally considered a legacy/discouraged mechanism today, since it creates real accessibility and user-control problems that more deliberate navigation methods (proper redirects, JavaScript-driven UX with clear user controls) avoid.

Syntax

Refresh: <seconds>
Refresh: <seconds>; url=<url>

Examples:

Refresh: 5
Refresh: 10; url=https://example.com/new-page

Without a url parameter, the browser reloads the current page after the delay. With one, it navigates to the specified URL instead — functioning as a delayed redirect.

How it's used in practice

• Delayed redirects with a visible transition message — some legacy patterns use Refresh to show a "you'll be redirected in 5 seconds" message before navigating, rather than redirecting instantly via Location with a 3xx status.
• Auto-refreshing dashboards or status pages — a page showing live-updating data (a build status page, a simple monitoring dashboard) might use Refresh: 30 to reload every 30 seconds, though modern implementations increasingly prefer JavaScript-based polling or WebSocket updates for a smoother, non-jarring experience.
• Session timeout warnings — occasionally paired with a countdown message before automatically navigating to a login page once a session has expired.
• Legacy CMS and hosting platform defaults — some older content management systems or simple static hosting setups still use meta-refresh or the Refresh header for basic redirect functionality, predating more modern server-side redirect configuration options.

Common mistakes and gotchas

Using it instead of a proper HTTP redirect. For an actual redirect with no intentional visible delay, a real 3xx status code with a Location header is almost always the better choice — it's semantically correct, doesn't depend on JavaScript or meta-tag processing, and is properly understood by search engines, screen readers, and other tools as an actual redirect rather than a page reload.

Accessibility problems with auto-refresh. A page that automatically refreshes or navigates away after a fixed delay can be a genuine accessibility barrier — screen reader users, people with cognitive disabilities, or anyone who simply needs more time to read content can lose their place or context involuntarily. WCAG guidelines specifically flag unexpected auto-refresh/redirect behavior as a concern, recommending users be given control to extend, postpone, or disable it.

Breaking the browser back button experience. An auto-refreshing or auto-redirecting page can create confusing back-button behavior, since the browser history may not reflect what the user expects after an automatic navigation they didn't initiate.

Search engines treating it inconsistently. Unlike proper 3xx redirects (whose SEO handling is well-defined — 301 passes link equity, 302 doesn't, etc.), Refresh-based redirects are handled less predictably by search engine crawlers, making it a poor choice for any redirect with SEO implications.

Real-world examples

Simple delayed reload:

HTTP/1.1 200 OK
Refresh: 30

Delayed redirect with a visible transition:

HTTP/1.1 200 OK
Refresh: 5; url=https://example.com/thank-you

Preferred modern alternative for an actual redirect:

HTTP/1.1 302 Found
Location: https://example.com/new-page

FAQ

Should I use Refresh or a proper 3xx redirect?

For an actual redirect, use a 3xx status with Location — it's the semantically correct, more predictable, and more accessible mechanism. Reserve Refresh only for genuine cases where you specifically want a visible delay before navigation, and even then, consider whether a JavaScript-driven UX with clear user controls (a "redirecting in 5s, click here to go now" pattern) would serve users better.

Is Refresh still supported by modern browsers?

Yes, broadly — both the header and the equivalent meta tag remain functional in all major browsers. Being supported doesn't mean it's recommended, though; it persists mainly for backward compatibility with legacy content.

What accessibility concerns does Refresh create?

Automatic page refresh or redirect after a fixed delay can disrupt users who need more time to read or interact with content — screen reader users and people with cognitive or motor disabilities are particularly affected. Accessibility guidelines recommend giving users control over timed content changes rather than forcing them.

Does using Refresh affect SEO?

Search engines handle Refresh-based navigation less predictably and consistently than standard 3xx HTTP redirects, which have well-established, well-understood SEO semantics. For any redirect where search ranking signals matter, a proper 301/302 redirect is the safer, more predictable choice.

Fun fact

The Refresh header and its meta-tag equivalent predate the standardization of proper HTTP redirect status codes achieving widespread, reliable browser support — in the earliest days of the web, using a timed refresh was sometimes the more consistently-working option across the wildly varying browser implementations of that era. It's a good example of a workaround that outlived the compatibility problem it was originally created to solve, persisting today mostly through legacy content and outdated tutorials rather than genuine technical necessity.