JWT — Intentionally Invalid Segments
Intentionally invalid JWT (truncated) for parser error-path tests.
eyJhbGciOiJub25lIn0.not-valid-payload
Specifications
- Valid
- false
- Issue
- missing signature segment / bad payload
Testing contract
Expected to fail- Scenario
- Exercise JWT — Intentionally Invalid Segments in its jwt workflow. Intentionally invalid JWT (truncated) for parser error-path tests.
- Expected result
- Report the intended validation failure (missing signature segment / bad payload); never silently treat it as a conforming input. 1 text lines, decoded as UTF-8; first nonempty line is 'eyJhbGciOiJub25lIn0.not-valid-payload'. Declared feature checks: valid=False; issue=missing signature segment / bad payload.
What is a .jwt file?
A JWT (JSON Web Token) is a compact, URL-safe token made of three base64url-encoded parts (a header, a payload of claims, and a signature) separated by dots. It is widely used to carry authentication and authorisation claims between services.
How to use this file
Use a sample JWT to test token decoding, claim extraction, and signature verification. Never use an example token's secret in production.
How to use this file for testing
“JWT — Intentionally Invalid Segments” is a deterministic Novus Examples fixture for JWT / JWKS testing, Error handling. Unsigned and SAMPLE-signed JWT variants plus JWKS documents, published sample material only, for auth parser tests.
Documented properties for this file: intentionally invalid. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such, expect parsers to fail loudly rather than silently accept them.
This is published, SAMPLE-only security material, never a real secret. Point certificate, key, or token parsers at it, test PEM/DER decoding and PKCS handling, and confirm your tooling reads the documented fields; any sample password is printed on this page.
These JSON fixtures are synthetic SAMPLE auth or tool-call shapes for harnesses, never production secrets or live tokens. Validate schema fields and alg variants against the documented role.
Code examples
cut -d. -f1 intentionally-invalid-segments.jwt | base64 -d; echo
cut -d. -f2 intentionally-invalid-segments.jwt | base64 -d; echo # payload claimsRelated files
- jwtJWT (HS256 Expired) — SAMPLESAMPLE HS256 JWT with a past exp claim — for expiry-validation harnesses.
- jwtSAMPLE JWT — alg none, UnsignedAn unsecured JWS: alg is none and the signature segment is empty, leaving only the trailing dot. Any verifier that accepts it will accept a claim set an attacker wrote, which is why this is the first negative test to run.
- jwtSAMPLE JWT — Algorithm Confusion (HS256 over an RSA Public Key)The classic algorithm-confusion shape: a token that claims HS256 while its kid points at an RSA key, MACed with that key's public PEM as the shared secret. A verifier that picks its algorithm from the header rather than from the key type accepts it.
- jwtSAMPLE JWT — EdDSA, Bad SignatureThe EdDSA token with one bit of its signature flipped. Ed25519 verification either succeeds or fails with no partial credit, which makes this the cleanest possible negative case.
- jwtSAMPLE JWT — RS256, Bad SignatureThe valid RS256 token with the last bit of its signature flipped. Header and payload are byte-identical to the valid twin, so any difference in outcome is entirely down to signature verification.
- jwtSAMPLE JWT — RS256, ExpiredA correctly signed RS256 token whose exp passed on 2020-01-01. The signature still verifies, so it isolates expiry handling from every other check — including the libraries that validate the signature and then forget to look at exp.
Generated by generation/security_wave_g.py. Free for any use, no attribution required, license.