How many segments does a signed JWT have?

A compact JWS normally has three dot-separated segments: header, payload, and signature.

Should Bearer be included when decoding a JWT?

No. Remove the Authorization scheme and pass only the token value.

Why does an encrypted JWT have five segments?

Compact JWE uses five segments and requires a library that supports encrypted tokens.

"jwt malformed" / "Not enough segments" Error, Explained

This error fires before a JWT library even looks at the signature or claims — it means the string you handed it isn't shaped like a JWT at all.

What triggers it

A JWT is exactly three base64url segments joined by dots: header.payload.signature. Libraries typically split on . and check the count before doing anything else. You'll see this error (worded differently depending on the library — jwt malformed, Not enough or too many segments, invalid token specified) when:

The token got truncated — a copy-paste that missed the last few characters, or a database column too short to hold the full string.
You passed something that isn't a JWT at all: an API key, a session cookie value, or the whole Authorization: Bearer <token> header including the Bearer prefix.
The token has extra whitespace or a trailing newline from being read out of a file or environment variable.
It's actually a JWE (encrypted JWT) — those have five segments, not three, and a JWS-only library will reject them as malformed.

How to check it quickly

Paste the raw string into the JWT Decoder. If it's genuinely malformed, you'll see exactly that — a segment-count or base64 decode failure — before any signature check runs, which tells you the problem is in how the token was captured or stored, not in your verification logic.

Trace where the token changed

Compare the token at the issuer, transport boundary, and verifier without logging the complete credential. Record only its length, segment count, and a short cryptographic hash in a protected debug environment. If those values change, the token was truncated, prefixed, wrapped, or decoded before it reached verification. Check database column length, environment-variable quoting, proxy header limits, and newline handling in secret files.

After confirming three segments, decode header and payload as Base64URL, not ordinary Base64. Missing padding is normal in JWT compact serialization. A successful decode is still not authentication: verify the signature, issuer, audience, expiration, and any application-specific authorization claims before trusting the payload.

Frequently Asked Questions

How many segments should a signed JWT have?

Usually three: header, payload, and signature.

Should I pass the `Bearer` prefix?

No. Pass only the compact token value to the decoder or verifier.

Why does my token have five segments?

It may be a compact JWE, which needs encrypted-token support rather than a JWS-only verifier.