How to Fix 422 Unprocessable Entity Error

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

What 422 Unprocessable Entity means

HTTP status 422 sounds technical, but the idea is simple. When you submit a form, upload a file, or send data to an app, the server checks that data against a set of rules: which fields are required, what format each value must take, and which combinations are allowed. If the request arrives intact and readable but breaks one of those rules, the server answers with 422 Unprocessable Entity. It understood you perfectly well; it just cannot accept what you sent.

You will meet 422 errors most often on sign-up forms, checkout pages, profile editors, file uploads, and API calls. The message may appear as 422 Unprocessable Entity, Unprocessable Content (the newer name for the same status), or a form error listing the fields that failed. The good news is that a 422 is one of the most fixable errors on the web: the server is telling you exactly what is wrong, and correcting that data almost always clears it. It is not a broken website, a bad connection, or a hacked account — it is a data mismatch, and it usually takes one careful pass over the form to resolve.

Common causes

• Missing required fields: a field marked required was left blank, or a dropdown was left on its placeholder option instead of a real choice.
• Values in the wrong format: an email without an @ sign, a date in the wrong order, a phone number with letters in it, or a number field containing currency symbols or commas.
• Values that break a business rule: an end date earlier than a start date, a quantity of zero, a password shorter than the minimum length, or an age below the allowed range.
• Malformed JSON or wrong headers in API requests: mismatched braces, a trailing comma, strings without quotes, or a JSON body sent without the application/json content type.
• Stale or mismatched form data: a form left open while options changed on the server, an expired session token, or a file that exceeds the size limit or uses an unsupported type.

How to fix the 422 Unprocessable Entity error — step by step

Start with the visitor steps (1–5). If you own the site or the API, step 6 is where persistent 422 errors get fixed.

1. Read the validation message carefully. A 422 response almost always carries a message that names the problem, so do not guess. Read the error shown on the page, and if you are working with an API, open the full response body: it usually lists exactly which fields failed and why, such as email is required, price must be a number, or start date must be before end date. Note the field names and the rules they broke, because those messages are your fix list. If the page shows only a generic 422 message, press F12, open the Network tab, click the failed request, and read the Response tab for the detailed validation errors.
2. Fill in every required field and fix the flagged values. Go back to the form or request and check every field the error flagged. Fill in any required field you left blank, and correct values that break the stated rules: an email address must contain an @ sign and a domain, a phone number must match the expected format, a password must meet the minimum length, and a number field must not contain letters or symbols. For dropdowns and checkboxes, make sure you actually selected an option rather than leaving the placeholder choice in place. Fix one field at a time and resubmit, so you can see which correction cleared the error.
3. Check data formats, dates, and file uploads. Many 422 errors come from a value that looks right to a person but is wrong for the server. Dates must match the expected format, such as YYYY-MM-DD, and a future date will fail a rule that requires a past date. Amounts must use a plain number without currency symbols or commas. For file uploads, check the allowed file types and the maximum size: a 20 MB video will fail a 10 MB limit, and a .heic photo will fail a rule that only accepts .jpg and .png. Resize or convert the file, then upload it again.
4. Fix JSON syntax and headers for API requests. If you are sending an API request, a 422 can mean the data itself is malformed even though the server understood the request. Check that your JSON has matching braces and brackets, that every string is wrapped in double quotes, and that there is no trailing comma after the last item. Make sure the Content-Type header is set to application/json when you send JSON, and that the body is not accidentally sent as form data. Paste the body into a JSON validator to catch syntax errors before you resend the request.
5. Refresh, clear stale form data, and resubmit once. A form that was open for a long time can carry stale values, such as an expired option, a deleted category, or a session token that no longer matches the server. Refresh the page to load the current options, re-enter your values, and submit again. If the form still fails, clear the site cookies by pressing Ctrl + Shift + Delete, checking Cookies and other site data for that site, and clicking Clear data, then sign in again and retry. Avoid hammering the submit button: repeated identical submissions will return the same 422 and can trigger rate limits.
6. Site owner: fix the validation rules and check the logs. If you own the site or API, a wave of 422 errors usually points at a validation rule that is too strict or out of sync with your form. Compare the fields your form sends with the fields your server validates, and check for a rule that rejects valid input, such as a date rule that rejects today's date or a size limit lower than your form promises. Check the server logs for the exact payloads that failed, and make the error messages name the field and the rule so users can fix their input. If a recent deploy changed a rule or a field name, roll that change back or update the form to match, then test a full submission end to end.

Did this fix it? Quick checklist

• The form or request submits without a 422 message
• Every field named in the validation message is corrected
• Dates, numbers, and uploads match the required formats and limits
• Site owners: form fields and server validation rules agree, and errors name the field

If the error only appears on one form while others work fine, that form is the problem, not your account or connection: compare its fields against the error message one by one. If you are a developer and the same payload fails in production but works locally, check for a validation rule, database constraint, or environment difference between the two — a rule that exists only on the live server is a common culprit.