How to Fix 412 Precondition Failed Error

By ErrorFix · Updated October 25, 2026 · 7 min read

What 412 Precondition Failed means

When your browser or an app talks to a website, it can attach conditions to a request. The most common are If-Match, which carries an ETag — a short fingerprint of the version of a file or page you last saw — and If-Unmodified-Since, which carries a date. These headers say, in effect: only carry out this request if the resource has not changed since I last saw it. HTTP status 412 means the server checked that condition and found it false. In plain terms, the thing you are trying to submit, save, or download has changed since you loaded it, so the server refused to act on your outdated copy rather than risk overwriting newer data.

You will usually meet a 412 on form submissions, document saves, file uploads, and API calls rather than on ordinary page loads. A classic example is an editing form left open in a tab while someone else edits the same page, or a file upload retried after the file on the server was replaced. The 412 is actually a safety feature: it stops two people from silently overwriting each other's work. It is not a missing page and not a permission problem — it is a version mismatch between what your browser remembers and what the server currently holds.

Common causes

• Stale cached copy or ETag: your browser, a caching plugin, or a CDN serves an old version of the resource, so the precondition you send no longer matches the current one.
• Resource changed since you loaded it: another user edited the page, or the file on the server was replaced, while your tab or form sat idle.
• Conflicting edits or concurrent requests: two tabs, two users, or a retried request submit changes based on the same old version, and the second one fails the check.
• Proxy or filter rewriting headers: a corporate proxy, firewall, or content filter strips or alters conditional headers, so the server sees a precondition that cannot pass.
• Server clock drift or faulty ETag handling: a server clock that has drifted makes date-based preconditions fail, and an application that never updates its ETags makes every update look stale.

How to fix the 412 Precondition Failed error — step by step

Start with the visitor steps (1–3). If you own the site or the code, steps 4–6 are where most persistent 412 errors get fixed.

1. Hard refresh and clear your browser cache. A 412 is most often caused by a stale cached copy of the page or file, so start by forcing a fresh request. Press Ctrl + F5 for a hard refresh, which tells the browser to skip its cache and ask the server again. If the error persists, press Ctrl + Shift + Delete, set the range to All time, check Cached images and files and Cookies and other site data, and click Clear data. Then close and reopen the browser tab and try the action again. If it works after this step, a cached ETag or a cached copy of the resource was the whole problem.
2. Re-fetch the resource before you resubmit. Precondition errors commonly appear when you submit a form, save a document, or upload a file that has changed since you first loaded it. Someone else may have edited the same page, or the file on the server may have been replaced while your tab sat idle. Reload the page to get the current version and its fresh ETag, then make your change and submit again right away instead of reusing the old form. On an API call, issue a fresh GET first and use the ETag from that response in your next request.
3. Try incognito and a different network. Open an incognito window (Ctrl + Shift + N) and repeat the same action. If it works there, an extension, a cookie, or a cached file in your normal window is sending the stale precondition header. If it still fails, switch networks, for example from office Wi-Fi to your phone's mobile data: some corporate proxies and content filters rewrite or strip conditional headers, and a different network rules that out. If the error follows you across browsers and networks, the problem is on the server side.
4. Site owner: purge CDN, plugin, and server caches. If you own the site, purge every cache layer that could be serving an old ETag: your CDN cache, your caching plugin, and any reverse proxy in front of the origin. In WordPress, purge the cache in your caching plugin and, if you use Cloudflare, purge the affected URLs under Caching and Purge Cache. Then test the same action in a fresh browser profile. A cache that serves a stale ETag after the underlying file changed will keep producing 412 responses until it is purged.
5. Fix ETag and precondition handling on the server. Check how your server generates ETags and handles conditional requests. A server that sends a strong ETag for a resource that changes on every request, or an application that compares If-Match against an outdated stored version, will reject legitimate updates. Make sure your application returns the current ETag on every GET, updates it whenever the resource changes, and only returns 412 when the precondition genuinely fails. If your framework handles conditional requests itself, check that it is not applying If-Match or If-Unmodified-Since checks to routes that should not have them.
6. Check server clock sync and inspect the request headers. Preconditions based on dates, such as If-Unmodified-Since, depend on clocks agreeing. If the server clock has drifted, a request that should pass can fail. On a server you control, make sure NTP time sync is running and the clock is accurate. For diagnosis, open your browser's developer tools with F12, go to the Network tab, and look at the failed request: the Request Headers section shows exactly which precondition header was sent, such as If-Match or If-Unmodified-Since, and the Response Headers show the current ETag and Last-Modified values to compare against.

Did this fix it? Quick checklist

• The form, save, or upload completes without a 412 message
• A hard refresh or a fresh reload produces the current version of the page
• It works in an incognito window and after clearing cache
• Site owners: no CDN, plugin, or proxy cache still serves a stale ETag

If the error only appears on one network, such as office or school Wi-Fi, a proxy on that network may be rewriting your conditional headers — try your phone's mobile data to confirm. On the owner side, if the 412 started right after adding a caching layer, moving hosts, or changing CDN settings, that change is the prime suspect: purge or roll it back temporarily and test before digging into application code.