HTTP Status Codes Quiz
Practice 32 HTTP status codes with recognition questions and web scenarios, then review explanations and retry the distinctions you missed.Practice status
{{ summaryLine }}
{{ quizIssue }}
{{ seedNotice }}
{{ quizSetupValidation }}
{{ progressStatusLine }}
Question {{ quizCursor + 1 }} of {{ questionCount }}
{{ currentQuestion.stem }}
{{ currentQuestion.accessible_clue }}
{{ currentResultRow.feedback }}
Response class: {{ currentResultRow.category_label }}
{{ currentResultRow.explanation }}
Answer recorded. Review the correct code and explanation at the end.
Review what to practice next
{{ resultLead }}
Practice score only. This round does not establish proficiency or predict performance on a certification exam.
{{ learningReviewTitle }}
No missed answers in this round.
{{ learningReviewLine }}
Missed answer review
-
{{ item.prompt }}
Your answer: {{ item.selected_answer_label }}
Correct answer: {{ item.correct_answer_label }}
{{ item.explanation }}
Source: {{ item.source.version }}
Response-class performance
Which response classes need another look? Counts describe only this round; absent classes were not sampled.
Loading topic-performance chart…
{{ quizChartExportStatus }}
Answer ledger
| Question ID | Prompt | Topic | Your answer | Correct answer | Outcome | Explanation | Source | Copy |
|---|---|---|---|---|---|---|---|---|
| {{ row.question_id }} | {{ row.prompt }} | {{ row.category_label }} | {{ row.selected_answer_label }} | {{ row.correct_answer_label }} | {{ row.outcome_label }} | {{ row.explanation }} | {{ row.source.version }} · {{ row.source.label }} |
{{ quizLedgerExportStatus }}
A web request can be accepted without the work being finished. When a service queues a report and returns 202 Accepted, the report may still fail later. Treating that response as completed work can make an application announce a result that does not yet exist.
Hypertext Transfer Protocol (HTTP) status codes communicate the outcome or progress of a request between a client and a server. The client might be a browser or an application using an application programming interface (API). A response combines its three-digit status with headers and, when permitted, content. The number gives a standardized meaning, while the other response information explains details such as a new address, an authentication requirement or the reason for a refusal.
The request also matters. A resource is the object being addressed, such as a document or project record. Its representation is the data describing it, such as a document body or a structured data record. The method says what the client is asking to do. For example, GET retrieves a representation, while POST asks the resource to process submitted information. The first digit of the response code identifies its broad class.
| Response class | What it communicates |
|---|---|
| 1xx Informational | Information about request progress or a protocol change, rather than an ordinary final application result. |
| 2xx Success | Successful receipt, understanding and acceptance, with the exact code distinguishing completed work from work merely accepted for processing. |
| 3xx Redirection | Further action such as requesting another address or reusing a stored representation after validation. |
| 4xx Client error | A request that is invalid or cannot be fulfilled under the stated conditions. |
| 5xx Server error | A server failure or inability to fulfill an apparently valid request. |
Not every response outside 2xx represents a failed user task. A cache stores response data for later reuse. After a conditional retrieval checks that its copy is still valid, 304 Not Modified lets it reuse that copy without another content transfer. This belongs to the redirection class even though it does not send the browser to another address.
Similar-looking failures can call for different corrections. Missing valid credentials, an access-policy refusal, an unsupported upload format and a request-rate limit are separate conditions. Likewise, a gateway, which forwards requests to another server, can report either an invalid upstream response or a timeout while waiting for one. Those distinctions help developers and support engineers decide which request details or server records to inspect.
A status code is not a complete diagnosis, a measure of overall website health or permission to retry every operation. The method, headers, response explanation and service behavior still matter. Repeating a submission can duplicate an action when the original request was applied but its outcome is unclear. Recognizing the code is the starting point for understanding that particular exchange.
How to Use This Tool:
Choose recognition practice for short meaning-to-code questions or scenarios for applying those meanings to web situations. The bank contains 64 original text questions covering 32 selected codes, with one recognition question and one scenario for each code. It is not a live website check.
- Choose a Set. The default is Recognition · all 32 codes. Scenarios · all 32 codes covers the same codes through situations, while the focused scenario sets cover 1xx and 2xx together, 3xx redirection, 4xx client errors or 5xx server errors.
- Choose the Question count. Both all-code sets offer 2, 5, 10 or 32 questions, with 10 selected initially. The 1xx/2xx set offers 2, 5 or 7, and the 3xx set offers 2, 5 or 6. The 4xx set offers 2, 5, 10 or 14, while the 5xx set offers 2 or 5. A 32-question round covers one question format, not all 64 questions.
- Choose Feedback. Explain after each answer, the default, reveals correctness and the explanation before you advance. Review at the end records each choice but withholds correctness and explanations until the completed review.
- Enter an optional Replay seed under Advanced to make a round reproducible. Leave it blank to generate a new seed, or retain it and the same setup to repeat the questions and option order while the question bank remains unchanged.
The seed accepts up to 128 characters. If a seed warning appears, clear or replace it. Starting with an unusable optional seed creates a new seed instead of reproducing the intended round.
- Select Start practice and choose the best of the four listed codes for each question. A choice locks as soon as you select it. Advance with Next question, then use View results after the last answer. There is no skipped-question or early-finish result.
- Review the explanations in Missed answer review or the Answer ledger. After completion, Retry missed starts a new attempt using only wrong answers, Replay same seed repeats the current round, and Try a new seed starts another seeded round. Perfect rounds have no missed-answer retry.
Interpreting Results:
During a round, Practice status reports how many questions you have answered. Its progress percentage measures completion, not correctness. After the round, the main fraction reports correct answers out of the selected question count.
The Response-class performance chart shows counts of Correct and Missed answers for the classes sampled in that round. An absent class was not tested. Short rounds need not cover all five classes, and even a full round contains unequal numbers from each class. A larger missed count can therefore reflect more questions from that class, not necessarily a lower success rate.
Review focus points to a class with the most missed answers, rather than measuring proficiency or ranking classes by percentage. Use the Answer ledger to compare your selected code with the correct code, explanation and source for each question. This identifies a specific confusion to revisit instead of reducing the attempt to one total.
A Perfect round means there were no wrong answers in that attempt. There is no official pass mark, proficiency band or certification prediction. These are independently authored practice questions without endorsement from the Internet Assigned Numbers Authority (IANA) or the Internet Engineering Task Force (IETF).
Technical Details:
HTTP response meanings depend on the request method and the condition being reported. A general error and a more specific error may sound plausible, but a request without valid credentials, a rejected request-header condition and an invalid upstream response describe different events. Scenario answers use the most specific listed code supported by the stated facts.
Selected status meanings
The following reference covers the 32 codes included in practice, not the complete registry. Each row gives the condition that distinguishes that code from nearby alternatives.
Interim responses and successful outcomes
| Code | Name | Meaning and deciding clue |
|---|---|---|
| 100 | Continue | An interim response inviting the remaining request content, such as after Expect: 100-continue. It does not establish final success. |
| 101 | Switching Protocols | An agreed protocol switch in an HTTP/1.1 exchange. The response includes Upgrade to identify the selected protocol. |
| 200 | OK | The request succeeded. Content depends on the method. A successful HEAD response, for example, has no response content. |
| 201 | Created | Processing completed and created one or more resources. The primary new resource is identified by Location, or by the request target when that header is absent. |
| 202 | Accepted | Processing was accepted but has not finished. Eventual completion is not guaranteed. The response should describe the current status and provide a way to monitor it. |
| 204 | No Content | The request completed successfully without response content or trailing fields, called trailers. Response headers can still describe the resulting resource. |
| 206 | Partial Content | A range request is being fulfilled. For a single byte range, Content-Range identifies the transferred segment. |
Redirection and conditional retrieval
A relocation can be temporary or permanent, and following it can preserve or change the request method. Those are separate decisions. A conditional retrieval instead checks whether a stored representation can still be used.
| Code | Name | Meaning and deciding clue |
|---|---|---|
| 301 | Moved Permanently | Permanent relocation. Historical behavior permits, but does not require, changing a redirected POST to GET. |
| 302 | Found | Temporary relocation with the same permission to change POST to GET. |
| 303 | See Other | Another resource supplies an indirect response through retrieval, using GET or HEAD. This commonly separates a completed submission from its receipt page. |
| 304 | Not Modified | A conditional GET or HEAD can reuse a stored representation. There is no response content or trailer section, and no address-based relocation is implied. |
| 307 | Temporary Redirect | Temporary relocation that requires the request method to remain unchanged during automatic redirection. |
| 308 | Permanent Redirect | Permanent relocation that preserves the request method during automatic redirection. |
Client errors and request conditions
A precondition is a condition supplied in request headers and checked before the requested action. An entity tag, sent in ETag, identifies a representation version. Comparing tags can validate a stored copy or prevent an update from overwriting changed data.
| Code | Name | Meaning and deciding clue |
|---|---|---|
| 400 | Bad Request | A perceived client error, such as malformed request syntax or message framing. It is broader than a specific format or precondition failure. |
| 401 | Unauthorized | The request lacks valid authentication credentials. The response must include a WWW-Authenticate challenge. |
| 403 | Forbidden | The server understands the request but refuses it. Successful authentication is not a prerequisite for this code. |
| 404 | Not Found | No current representation was found, or the server will not reveal one. This does not establish whether the absence is permanent. |
| 405 | Method Not Allowed | The server knows the method, but the target resource does not support it. An Allow header must list the currently supported methods. |
| 408 | Request Timeout | The server did not receive the client's complete request within its waiting period. This is not an upstream response timeout. |
| 409 | Conflict | The request conflicts with the resource's current state, such as an edit needing a merge. A failed HTTP header precondition is a more specific condition. |
| 410 | Gone | Access is unavailable and the condition is likely permanent. Unlike a permanent redirect, it does not identify a replacement address. |
| 412 | Precondition Failed | A supplied request-header condition evaluated to false. A rejected update carrying an old If-Match tag is an example. |
| 413 | Content Too Large | The request content exceeds what the server will process. When the restriction is temporary, the server should include Retry-After. |
| 415 | Unsupported Media Type | The request's content format or coding is unsupported for that method and resource. This is not a content-size refusal. |
| 416 | Range Not Satisfiable | No requested range can be satisfied, or the request contains too many small or overlapping ranges. A byte-range rejection should report the current length in Content-Range. |
| 422 | Unprocessable Content | The content type is understood and syntax is valid, but the contained instructions cannot be processed. |
| 429 | Too Many Requests | The caller exceeded a request-rate allowance. Retry-After is optional, and the service defines how requests and callers are counted. |
A conditional GET whose If-None-Match tag matches the current representation can produce 304. A rejected update with an old If-Match tag is the 412 case practiced here. Likewise, a request containing Range does not guarantee a 206 or 416 response because a server can ignore the range and send a full representation.
Server and gateway errors
The distinction between receiving the client's request and waiting for an upstream server is especially important for timeout questions. The origin server handles the resource, while a gateway or reverse proxy may contact another server to fulfill the request.
| Code | Name | Meaning and deciding clue |
|---|---|---|
| 500 | Internal Server Error | An unexpected server condition prevented fulfillment. The code alone does not identify a particular bug. |
| 501 | Not Implemented | Required server functionality is unsupported, such as an unrecognized method that cannot be supported for any resource. |
| 502 | Bad Gateway | A gateway or proxy received an invalid response from an upstream server. |
| 503 | Service Unavailable | Temporary inability to handle the request, commonly because of overload or maintenance. Retry-After may be provided. |
| 504 | Gateway Timeout | A gateway or proxy did not receive a timely response from an upstream server. |
A retry delay does not guarantee that the next request will succeed. Automatic retries also need to account for whether repeating the operation has the same intended effect. A timeout alone does not establish that a state-changing request was never applied.
Question selection and coverage
Questions are selected without replacement within the chosen set. Each question offers its correct code and three authored alternatives, with seeded question and option ordering. Across either complete 32-question format there are 2 informational, 5 success, 6 redirection, 14 client-error and 5 server-error questions.
A new seed can repeat previously seen questions. Choosing every question in a set necessarily repeats that set's content, even when its order changes. Exact replay depends on retaining the setup, seed and unchanged question bank. Retrying missed questions narrows the next attempt to that missed-question pool rather than measuring the full original scope again.
The question bank records a source check dated 11 September 2026. It is fixed, curated practice rather than a live registry lookup. Other registered codes, including extension-specific and temporary entries, are outside its coverage, as are unused and unassigned codes.
Score and progress
Each correct answer earns one point and each wrong answer earns zero. There is no partial credit, weighting, reverse scoring or deduction. Feedback timing does not change the score. Accuracy uses the entire selected round as its denominator, while progress counts all recorded answers.
C is the number of correct answers, N is the selected question count, and R is the number answered. S is the score in points out of N possible points. A and P are accuracy and progress in percent. The counts C, R and N are integers with 0 ≤ C ≤ R ≤ N and N greater than zero. The completed headline displays the correct-count fraction rather than a proficiency rating.
The score ranges from zero to the selected question count. Unanswered questions remain in the denominator during a partial attempt, but they are not counted as wrong or included among missed answers. A final result requires every selected question to be answered. The visible progress label rounds to the nearest whole percent, with half-percent ties upward. Calculated accuracy retains its unrounded ratio; the completed headline shows the exact correct count out of the selected total.
For example, two correct answers and one wrong answer in a planned 10-question round give 30% progress and a computed 20% accuracy against the full round. The seven unanswered questions are not seven additional mistakes, and no completed score is available yet.
Privacy and Saved Attempts:
Scoring takes place in the browser. The page address carries the setup, replay seed, recorded choices and current question or review position so that a compatible link can restore a partial or completed attempt. The address is not encrypted progress storage or an account-based progress record.
- Anyone who receives an attempt link can restore the choices included in it. Avoid personal information or secrets in a replay seed.
- The address can remain in browser history or be transmitted when the page is loaded or shared. Change setup clears the current attempt and its address state, but does not erase older history entries or copies already shared.
- Page loading and the response-class chart can require network resources. Browser scoring does not establish offline availability, zero transmission or a site-wide logging and retention policy.
An incompatible or damaged attempt link produces Saved attempt unavailable and returns to setup instead of restoring a partial interpretation of the saved answers. Choose an available set, feedback mode and question count, then start a new round.
Worked Examples:
An update rejected because its tag is old
In Scenarios · 4xx client errors, the update question describes a PUT carrying an old If-Match entity tag. The current representation has a different tag and the server declines the update. Selecting 409 Conflict is marked incorrect; the explanation identifies 412 Precondition Failed. The deciding clue is the failed condition in the request header, rather than a general editing conflict. A useful review is to compare this with the separate scenario where a revision conflict occurs without an HTTP conditional header.
One gateway mix-up in a five-question round
Choose Scenarios · 5xx server errors with five questions. Suppose the only wrong answer is choosing 504 Gateway Timeout for the gateway that promptly receives an invalid upstream response. The completed score is 4/5, equivalent to 80%, and the class chart contains four correct answers and one miss. The missed explanation points to 502 Bad Gateway because the upstream replied, but its response was invalid. Retry missed creates a new one-question attempt for that distinction. Answering it correctly gives 1/1 for the retry, not a revised score for the earlier five-question round.
References:
- Hypertext Transfer Protocol (HTTP) Status Code Registry, Internet Assigned Numbers Authority, updated 15 September 2025.
- RFC 9110: HTTP Semantics, Internet Engineering Task Force, June 2022.
- RFC 6585, Section 4: 429 Too Many Requests, Internet Engineering Task Force, April 2012.