Content-Type vs body check
Related tools
Validators and utilities that complement Content-Type vs body check — same session, no sign-up.
Heuristic comparison of declared Content-Type (and charset hint) against a coarse sniff of the body start (JSON, HTML, XML, YAML). No remote fetch.
Coarse Content-Type vs first-bytes sniff for JSON, HTML, XML, YAML — heuristic only; does not decode charset or gzip.
How to use this tool
- Paste your sample in the input (or fetch from URL if this tool supports it).
- Run the main action on the page to execute Content-Type vs body check.
- Read the result, fix the source data or config, and re-run if needed.
What this check helps you catch
- Heuristic comparison of declared Content-Type (and charset hint) against a coarse sniff of the body start (JSON, HTML, XML, YAML). No remote fetch.
- Limits called out in the description (what this tool does not verify — e.g. live network reachability, issuer databases, or strict schema contracts unless stated).
- Structural or syntax mistakes that would break parsers, serializers, or the next step in your workflow.
FAQ
- What does Content-Type vs body check do?
- Heuristic comparison of declared Content-Type (and charset hint) against a coarse sniff of the body start (JSON, HTML, XML, YAML). No remote fetch. Use the form above, then see “How to use” and “What this check helps you catch” for behavior detail.
- Is this a substitute for server-side validation?
- No. Use it for manual checks and triage; production systems should still validate and authorize on the server.
- Where does processing happen?
- Most validators here run in your browser. If a tool calls an API, that is stated on the page. See the site privacy policy for data handling.
Content-Type vs Body Sniff helps you compare a response’s declared MIME type against the actual structure suggested by its first bytes. This is useful when an API, webhook, file endpoint, or proxy says it is serving JSON, HTML, XML, or YAML, but the payload may not match. Developers, QA teams, security reviewers, and integration engineers use this kind of check to catch misconfigured servers, broken content negotiation, and response tampering before it causes parsing errors or downstream failures.
How This Validator Works
This validator looks at two signals: the declared Content-Type header and a lightweight sniff of the body’s opening bytes. It then compares the declared media type with common structural patterns for formats such as JSON, HTML, XML, and YAML. The goal is not to fully parse or deeply validate the document, but to identify obvious mismatches that often indicate configuration issues, proxy rewriting, or unexpected content delivery.
- Declared type: The MIME type advertised by the server, such as application/json or text/html.
- Body sniff: A simple pattern check against the first bytes of the payload.
- Comparison result: A match, mismatch, or ambiguous outcome when the body is too short or too generic to classify confidently.
Common Validation Errors
- JSON declared, HTML returned: Often caused by an error page, login redirect, or reverse proxy response.
- XML declared, JSON returned: Common in API versioning mistakes or backend handler changes.
- Generic content type: Headers like text/plain or application/octet-stream may not describe the payload accurately.
- Missing or inconsistent charset: The body may be valid, but downstream parsers can still fail if encoding is unclear.
- Ambiguous first bytes: Some payloads begin with whitespace, comments, or wrappers that make sniffing inconclusive.
Where This Validator Is Commonly Used
- API testing: Verifying that endpoints return the expected media type before client parsing.
- Webhook inspection: Checking whether incoming payloads match the declared format.
- CDN and proxy debugging: Detecting header/body mismatches introduced by intermediaries.
- Security review: Identifying responses that may be misleading to browsers, clients, or automation.
- QA and release checks: Catching regressions when backend services change response formats.
Why Validation Matters
Many systems rely on the declared MIME type to decide how to parse, render, or route content. If the header and body disagree, clients may throw errors, display the wrong content, or silently process data incorrectly. In trust and safety workflows, mismatches can also hide login pages, error pages, or unexpected content behind an API endpoint. Validating the relationship between headers and body structure helps teams improve reliability, reduce parsing failures, and spot integration issues earlier.
Technical Details
- Scope: Lightweight structural sniffing, not full schema validation.
- Formats commonly recognized: JSON, HTML, XML, and YAML.
- Best effort behavior: Results may be ambiguous when the payload is truncated, compressed, encoded, or intentionally wrapped.
- Not a security guarantee: A matching MIME type does not prove the content is safe, authentic, or trustworthy.
- Useful signals: Header consistency, parser compatibility, and obvious format mismatches.
FAQ
What does “Content-Type vs Body Sniff” mean?
It means comparing the MIME type a server claims in the Content-Type header with the format suggested by the first bytes of the response body. If the header says JSON but the body starts like HTML, that is a mismatch. This check is useful for quickly spotting response problems without doing a full parse.
Does this validator fully parse JSON, XML, or YAML?
No. It performs a lightweight sniff of the body’s opening bytes and compares that to the declared type. That makes it fast and useful for spotting obvious mismatches, but it is not a replacement for full syntax validation, schema validation, or application-level parsing.
Why would a server return the wrong Content-Type?
Common reasons include misconfigured application code, reverse proxy rewriting, cached error pages, redirects to HTML login screens, or backend changes that were not matched by header updates. In API environments, a wrong Content-Type often appears during deployment issues or when an endpoint fails and returns a generic page instead of structured data.
Can a matching Content-Type still be misleading?
Yes. A response can declare the correct MIME type and still contain unexpected or unsafe content. This validator only checks format consistency, not authenticity, business logic, or security posture. It should be used alongside other checks such as authentication review, schema validation, and response integrity controls.
What if the body starts with whitespace or comments?
That can make sniffing less certain. Some formats allow leading whitespace, and some documents include comments or wrappers before the main content. In those cases, the result may be ambiguous rather than a clear match or mismatch. Ambiguity is often a sign that a deeper parser or additional context is needed.
Is this useful for browser security testing?
It can be. Browsers sometimes try to infer content type from the body, especially when headers are missing or incorrect. Checking for header/body disagreement helps identify cases where a response might be interpreted differently than intended. That said, this tool is for validation and debugging, not a complete browser security assessment.
How is this different from schema validation?
Schema validation checks whether structured data follows a defined contract, such as JSON Schema or XML Schema. This validator is much simpler: it only compares the declared media type with the body’s apparent format. It is best used as an early warning signal before deeper validation steps.
Can compressed or encoded responses affect the result?
Yes. If the body is compressed, encrypted, or otherwise transformed, a simple first-bytes sniff may not reflect the original document format. In those cases, the validator may produce an ambiguous result or a false mismatch. Decompressing or decoding the payload first usually gives a more reliable outcome.
Related Validators & Checkers
- JSON Validator
- XML Validator
- YAML Validator
- HTML Validator
- API Response Validator
- Content-Type Checker
- Response Header Checker