202 Status Code: What HTTP 202 Accepted Means

HTTP status code 202 means the server received your request, decided it looked valid, and agreed to work on it later — but has not finished it yet. Its reason phrase is Accepted.

A 202 is a promise to try, not a report that the job is done. That single difference is behind almost every question people have about it.

What is an HTTP status code?

Every time a browser or an app asks a server for something, the server answers with a three-digit number before it sends anything else. That number is the status code, and it tells the caller how to treat whatever follows.

The first digit sets the family. The 200s mean success, the 300s mean the thing moved, the 400s mean the request itself had a problem, and the 500s mean the server broke while handling it. So 202 sits in the success family, and the request was not rejected.

What does status code 202 Accepted mean?

It means the request was understood and queued. The server is telling you that processing has been handed off to something that runs separately, and that the outcome is not known at the moment the answer was sent.

Because the work is still pending, a 202 deliberately says nothing about whether it will succeed. The job can still fail after the 202 was returned, and the code will never be sent again to correct it. That is normal behaviour, not a bug.

How is 202 different from 200, 201 and 204?

A 200 OK means the work is finished and the result is in the response. A 201 Created means the work is finished and a new item now exists. A 204 No Content means the work is finished and there is simply nothing to send back.

A 202 is the only one of the four that ends without an outcome. If you treat it like a 200 and tell the user the job is complete, you will eventually tell someone their upload, payment or export succeeded when it silently failed an hour later.

When do servers send a 202?

Whenever accepting the request is quick but doing the work is slow. Typical cases include a bulk import, a video or image being converted, a report being generated, a batch of emails being queued, a payment handed to another system, or a scheduled job that only runs at night.

Servers also use it when the request has to be reviewed by a person or by another service before it can go ahead. The server cannot honestly say yes or no yet, so it says accepted.

What should be inside a 202 response?

Ideally, some way to find out what happened later. A well-built service returns a status address or a job identifier — a short code that names this one piece of work — so the caller can ask about that job again.

Some services also include an estimate of how long to wait before checking again. If a 202 comes back with an empty body and no identifier, there is no supported way to learn the result, and you are left refreshing the original screen and guessing.

How do you check what status code you actually received?

1. Open the page or repeat the action in a desktop browser.
2. Open the browser developer tools. On Chrome, Edge and Firefox this sits in the browser menu, under the More Tools or Web Developer section.
3. Choose the Network tab.
4. Reload the page or press the button again so the request is recorded while the tab is open.
5. Find the request in the list. The Status column shows the three-digit code the server sent.
6. Click that row and read the response headers and body to see whether a job identifier or a status address was returned.

Doing this while the tab is already open matters. The Network tab only records traffic that happens after it was opened, so a request made before that will not appear.

Why does a 202 look like nothing happened?

Because from the user's side, nothing visible did. The screen often says the request was submitted and then never changes, since the server has no reason to send a second message on its own.

There are three common versions of this. The job is genuinely still queued and will finish. The job failed after acceptance, and the failure was only written to a log the user cannot see. Or the job finished correctly but the interface never refreshed to show it.

What do you do when a 202 never turns into a result?

1. Wait out the stated window first, if the service gave one. Retrying inside it usually just adds a second copy of the same job.
2. Reload the screen where the finished item is supposed to land — the list, inbox or history — rather than the page that showed the confirmation.
3. Sign out and back in. Some interfaces only refetch job status on a fresh session.
4. Check the account's own activity or history section for the job identifier you were given.
5. If the same request has been accepted several times, note each attempt before contacting anyone. Duplicate jobs are much easier to untangle when the times are known.
6. Contact the service's support with the job identifier, the time you submitted it, and the account you used. Without the identifier, support has to search by guesswork.

Is a 202 an error you need to fix?

On its own, no. A single 202 on a request that was designed to run in the background is the server behaving correctly, and no change is needed.

It becomes a problem in two situations. The first is when a request that should be instant returns 202, which usually means the service moved it into a queue that the interface does not know how to follow. The second is when 202 responses stop being followed by any result at all, which points at a stalled queue or a worker process that is no longer running behind the service. In both cases the code is a symptom to report, not the thing to fix yourself.

Does a 202 affect search engines?

A 202 is not a code meant for page content, and search crawlers have no way to come back for the eventual result. If a page that should return content answers with 202, crawlers see a success with no usable page, which is worse than an honest error. Pages meant to be read should return 200; only background jobs should answer 202.