Pasting a response body as if it were headers
A blank line ends an HTTP header section. The parser ignores later body lines unless the next non-empty line is a valid request or response start line.
HTTP Header Parser for Request and Response Debugging
EncodingRuns in Your Browser (No Uploads)
Parse bounded HTTP request or response header blocks locally. Separate redirect hops, validate field names, preserve duplicates, mask sensitive values by default, and flag malformed lines or high-risk framing combinations without fetching a URL.
What to do next
Continue with a related workflow or open the next tool that usually follows this task.
Workflow guide
Analyze a Content-Security-Policy header before deployment
Use this workflow when a CSP blocks an expected resource, a candidate policy produces noisy reports, or a proxy changes the header you intended to ship. It combines local policy parsing with browser violation evidence and a final deployed-edge check, without treating static findings as a security certificate.
OpenRelated toolBase64 Encoder and Decoder | UTF-8, Base64URL, and Data URIs
Strictly encode UTF-8 and decode Base64, Base64URL, data URIs, and binary byte output locally.
OpenRelated toolCSP Header Analyzer | Review Effective Policy Directives
Review CSP policies, effective directives, source expressions, and enforcement context locally.
OpenRelated toolDeveloper Conversion Workbench | Query, CSS, Escape, Base, and Commit Tools
Convert bases, inspect queries, calculate px/rem, transform escapes, and build commit messages in one local workbench.
OpenHow to Use This Tool
Capture the exact request or response header block and keep its start line and blank boundary when available.
Remove production secrets and private customer data before creating a reusable fixture, even though parsing stays in this browser.
Paste the block and keep sensitive-value masking enabled when the report may be copied, downloaded, or shared.
Review each redirect or proxy block separately, including its line range, start line, groups, and duplicate count.
Resolve malformed-line warnings and investigate conflicting Content-Length, Transfer-Encoding plus Content-Length, or duplicate Host signals at the exact network hop.
Compare the report with the actual browser or server transaction; the tool does not fetch URLs, replay requests, validate policy semantics, or prove security.
When to Use This Tool
Redirect and proxy chain inspection
Keep 301, 302, authentication, proxy-tunnel, and final response blocks separate instead of combining headers from different hops.
Framing and duplicate triage
Find repeated fields per block and surface conflicting Content-Length, Transfer-Encoding plus Content-Length, and duplicate Host combinations for manual investigation.
Cache, CORS, and content grouping
Locate cache, CORS, content negotiation, request, response, cookie, authentication, security, and custom field names without claiming their values are correct.
Shareable debugging evidence
Create a normalized report with common credential, cookie, API-key, client-address, and WebSocket-key values masked by default.
Common Mistakes
Treating every repeated field as an error
Set-Cookie and authentication challenges can repeat intentionally. Review the field's protocol semantics and the block where it occurred.
Sharing an unmasked report
Local parsing prevents an upload, but clipboard text, downloads, screenshots, tickets, and chat messages can still expose credentials or identifiers.
Accepting folded lines as modern HTTP syntax
Obsolete folded values are unfolded only for inspection and always produce a warning. Do not regenerate them in a request or response.
Calling parser signals a security verdict
A suspicious framing combination needs hop-by-hop raw-message analysis. This tool does not model every proxy, HTTP version conversion, cache, CORS, CSP, or cookie rule.
Examples
Separate a redirect from the final response
The two response blocks stay separate and the Set-Cookie value is masked in the default export.
Input
HTTP/1.1 302 Found
location: https://api.example.com/v2
set-cookie: session=private; Path=/; Secure; HttpOnly
HTTP/2 200
content-type: application/json
cache-control: no-storeOutput
HTTP/1.1 302 Found
location: https://api.example.com/v2
set-cookie: [REDACTED]
HTTP/2 200
content-type: application/json
cache-control: no-storeReview a request with credentials and repeated Accept fields
The method keeps its original case, the Authorization value is masked, and both Accept fields remain visible for duplicate review.
Input
GET /v1/users?page=2 HTTP/1.1
Host: api.example.com
Authorization: Bearer private-token
Accept: application/json
Accept: text/plainOutput
GET /v1/users?page=2 HTTP/1.1
host: api.example.com
authorization: [REDACTED]
accept: application/json
accept: text/plainParsing boundaries and protocol signals
Input is limited to 500,000 UTF-8 bytes, 10,000 lines, 32,768 bytes per line, 2,000 accepted fields, and 20 header blocks. Limits are checked before large structures are rendered.
Request methods use the HTTP token grammar and keep their original case. Regular field names use the token grammar; lowercase HTTP/2 pseudo-headers are accepted only before regular fields without a warning.
A blank line closes a block. A following valid request or response start line opens another block; otherwise remaining non-empty lines are treated as body or trailing data and ignored with a count.
Obsolete folded lines are unfolded into the preceding value for forensic readability and reported. Invalid field names, empty names, disallowed control characters, orphan continuations, and separator-free lines are skipped rather than normalized into valid-looking fields.
Repeated fields are retained per block. The parser highlights invalid or conflicting Content-Length, Transfer-Encoding with Content-Length, and duplicate Host combinations, but a parser signal is not proof of exploitability; only the actual intermediaries and raw bytes can establish impact.
Frequently Asked Questions
Does the parser send headers or fetch the URL?
No. Parsing runs in this browser and the tool does not make a request to the pasted host. Analytics must not receive pasted header values.
Which values are masked by default?
Common authorization, proxy authorization, cookies, API keys, CSRF tokens, forwarding or client-address fields, and WebSocket keys are masked in report output. Redact any additional private names, URLs, IDs, or vendor-specific credentials before sharing.
Why are several response blocks shown?
Redirects, proxy tunnels, and repeated captures can contain more than one start line separated by blank boundaries. Fields from different hops must not be treated as duplicates in one response.
Is a repeated Set-Cookie field a conflict?
Not by itself. Set-Cookie normally uses separate field lines. The report marks expected repeats separately from singleton conflicts and fields that still require review.
Does a Transfer-Encoding plus Content-Length signal prove request smuggling?
No. It is a high-priority review signal. Impact depends on the HTTP version, raw message, parsing differences, normalization, and every proxy or server in the path.
Can this replace CORS, cache, cookie, or security-header testing?
No. Grouping only locates relevant field names. Use the matching request context, browser diagnostics, policy-specific tools, and destination behavior to evaluate semantics.
How This Tool Was Verified
Maintained and tested by SimpleWebUtilsReviewed
Method: We replayed “A redirect followed by a final API response” in HTTP Header Parser for Request and Response Debugging, keeping the guide's input unchanged. “Remove secrets at the source” and “Investigate high-risk framing signals” defined the normal path; “Flattening every redirect into one response” and “Calling a framing warning a confirmed exploit” defined the boundary review before the output was accepted.
Expected result: The parser kept the 302 and 200 responses as two blocks, masked three sensitive values, preserved repeated Set-Cookie fields, and flagged the conflicting framing headers.
Sources and standards
- RFC 9110: HTTP SemanticsRFC Editor / IETF
Related workflow guides
Use these focused guides when you need a practical workflow before opening the tool.
Workflow guide
Analyze a Content-Security-Policy header before deployment
Use this workflow when a CSP blocks an expected resource, a candidate policy produces noisy reports, or a proxy changes the header you intended to ship. It combines local policy parsing with browser violation evidence and a final deployed-edge check, without treating static findings as a security certificate.
Workflow guideVerify a cron schedule across time zones and DST
A cron expression is not a complete schedule until its field dialect, IANA time zone, starting instant, DST behavior, and missed-run policy are known. This workflow first converts every reference date to an explicit ISO 8601 instant, then inspects a five-field Unix cron expression field by field, compares future runs in local wall time and UTC, exercises a daylight-saving transition, and verifies the same cases in the production scheduler before a job is enabled.
Workflow guideDebug encoded query parameters without double-decoding them
Use this workflow when a callback, search link, webhook, or API request changes plus signs, repeated keys, JSON string escapes, or a nested return URL after more than one parser touches it.
Workflow guideInspect HTTP response headers before debugging APIs
Use this workflow when a browser request, API response, redirect, or CDN cache behaves differently than expected and you need a bounded, redacted header-level record before editing configuration.
Workflow guideFormat JSON for API debugging
Use this workflow when a compact response is hard to inspect, a fixture fails strict parsing, or a generic client error must be traced to an exact JSON location without confusing syntax with API-contract validity.
Workflow guideDebug API JSON faster with JSONPath expressions
Use this workflow when a bug report, test failure, or production log includes a large JSON payload and you need to isolate request IDs, statuses, pagination links, or nested error fields.
Workflow guideCheck the final response security headers before launch
Use this workflow to turn a curl -I or DevTools capture into repeatable release evidence. It checks the final response locally, separates enforced CSP from Report-Only monitoring, preserves deployment context, and ends with live verification plus the application checks that response headers cannot cover.
Workflow guideExtract and convert timestamps from API logs
Use this workflow to turn a small, redacted log or payload sample into reviewable timestamp rows while preserving field names, source lines, exact epoch precision, and explicit unit decisions.
Workflow guideBuild a UTC incident timeline from Unix timestamps
Use this workflow after you have identified the timestamp fields and need to order cross-system events, separate event time from ingest time, account for clock skew, and explain the result without overstating causality.
Workflow guideCheck JWT expiration and not-before timestamps
Use this workflow to determine whether a request occurred before nbf, at or after exp, or inside the stated token window, while documenting clock-skew policy and removing the raw token from shared evidence.
Workflow guideDiagnose and recover one double-encoded query value
Use this workflow when a callback, webhook, proxy, SDK, or copied link contains `%252F`, `%2520`, `%253A`, or another sign that a percent sign was encoded again.
Workflow guideDebug a callback URL without losing query order or encoding evidence
Use this workflow when an OAuth, SSO, webhook, campaign, or application callback looks correct in a browser but the receiving system reads another path or parameter value.
Related Tools
Continue with another maintained workflow
Base64 Encoder and Decoder | UTF-8, Base64URL, and Data URIs
Strictly encode UTF-8 and decode Base64, Base64URL, data URIs, and binary byte output locally.
Encoding
CSP Header Analyzer | Review Effective Policy Directives
Review CSP policies, effective directives, source expressions, and enforcement context locally.
Security
Developer Conversion Workbench | Query, CSS, Escape, Base, and Commit Tools
Convert bases, inspect queries, calculate px/rem, transform escapes, and build commit messages in one local workbench.
Converter
JWT Decoder: Inspect Claims and Expiration
Strictly decode JWT structure and time claims locally without verifying the signature.
Security
Security Headers Checker | Final HTTP Response Review
Review the final pasted HTTP response for enforced and context-dependent security-header signals.
Security
URL Parser and Analyzer | Query Parameters and Relative URLs
Parse absolute URLs or resolve references with raw, decoded, normalized, and duplicate-query views.
Converter