Does PASETO v4.local end up larger than JWT HS256?

Not meaningfully — both are compact for an identical payload. In this playground you can watch the exact byte counts update live. JWT HS256 adds three Base64URL segments. PASETO v4.local adds a v4.local. prefix plus a 24-byte nonce and a 16-byte authentication tag. For a typical small payload the two are within a handful of bytes of each other — far smaller than XML-based formats like SAML.

Does JWT have an equivalent of the PASETO footer?

Roughly speaking, yes — JWT puts key identification in the header ( kid ), while PASETO puts it in the footer . But there's a subtlety worth seeing in this tool: JWT's header is untrusted and part of every JWT. In PASETO, the footer is optional and authenticated — it's covered by the encryption tag, so it can't be altered undetected. The footer is still unencrypted, so it should carry routing hints or a kid , never secrets.

Internal testing

JWT HS256 vs PASETO v4.local — Token Comparison Playground

Side-by-side: the same payload signed as JWT HS256 and encrypted as PASETO v4.local, using the same key — all in your browser.

Shared JSON payload

{
  "sub": "user_123456",
  "name": "Jane Doe",
  "iss": "https://auth.example.com",
  "aud": "my-api",
  "role": "admin",
  "scopes": [
    "read",
    "write",
    "admin"
  ],
  "iat": 1787814884,
  "exp": 1787818484
}

Shared key (32 bytes, base64url)

The same key signs the JWT and encrypts the PASETO token.

PASETO footer (optional, authenticated)

JWT has no footer field — shows the format asymmetry.

What is the Token Comparison Playground?

When teams debate tokens, it is usually framed as "JWT versus PASETO" as if each were a single thing. In practice each format has two very different flavors, and mixing them up is where teams get burned.

JWT HS256 — a *signed* token: it proves authenticity and integrity, but its payload is readable by anyone who holds it.

PASETO v4.local — an *encrypted* token: the same claims are sealed with XChaCha20-Poly1305 so only someone with the key can read them.

Same input, honest comparison — feed in one JSON payload and one 32-byte key, and this playground produces both tokens from the very same input.

This playground gets that distinction out of the abstract and onto the screen. You can see, not just read about, the three-part JWT with its negotiated `alg` header, and the versioned PASETO with its fixed algorithm, nonce, and authentication tag — and you can watch the byte sizes and timing sit side by side in real time.

Zero-Server Tool Data Guarantee

All comparison generation, JWT signing, PASETO encryption, and decryption happen entirely in your browser using the Web Crypto API and tweetnacl. Tokens, secrets, and keys never leave your device.

How to Use

Enter a JSON payload

Type or paste any JSON object, or load a ready-made template (basic, claims, or OIDC) to seed common claim shapes.

Set the shared key

Enter a 32-byte key as base64url, or click Random to generate one. The same key signs the JWT and encrypts the PASETO token.

Optionally add a PASETO footer

Add a footer such as a kid for key identification. JWT has no footer, which visually highlights the format difference.

Generate both tokens

Click Generate to produce the JWT HS256 and PASETO v4.local tokens from the same payload and key, with byte sizes and per-format timing.

Verify the round-trip

The tool checks the JWT signature and decrypts the PASETO token to confirm both recover the exact original payload.

JWT HS256 vs PASETO v4.local

Property	JWT HS256	PASETO v4.local
Structure	header.payload.signature	v4.local.nonce+ciphertext[.footer]
Primitive	HMAC-SHA256	XChaCha20-Poly1305 (AEAD)
Payload visibility	Readable (Base64URL only)	Encrypted
Algorithm negotiation	Header alg (agility risk)	Fixed per version
Key ID	kid in header	kid in authenticated footer
Typical overhead	~3 Base64URL segments	+24-byte nonce, +16-byte tag

Production Best Practices & Security

Signed does not mean secret. A verified JWT HS256 proves it wasn't tampered with; it does not keep its claims private.

Encryption and signature are different guarantees. v4.local gives you confidentiality *and* authentication in one primitive; HS256 gives you authenticity only.

Size is a wash. For a real claim set both tokens land within a few dozen bytes of each other — pick based on requirements, not bytes.

Match the format to the data. Put sensitive claims in v4.local; keep lightweight, non-sensitive identity claims in an HS256 JWT.

Never share a long-lived symmetric key. Whether HMAC or v4.local, rotate the key and store it in a KMS or secrets manager, never in source.

Frequently Asked Questions

JWT HS256 is a signed, self-contained token: header.payload.signature, where the signature is an HMAC-SHA256 over those first two parts using a shared secret. Anyone who holds the token can read the payload — it is only Base64URL-encoded, never encrypted.

PASETO v4.local is an encrypted token: v4.local.nonce+ciphertext[.footer]. The payload is sealed with XChaCha20-Poly1305, so it is both confidential and authenticated. There is no header, and the cryptographic algorithm is fixed by the version rather than declared in the token.

That one design choice — signing vs. authenticated encryption — is the core difference this playground lets you feel side by side.

JWT's payload is only Base64URL-encoded, which is obfuscation, not encryption. Paste it into any decoder and the claims are right there. HS256 protects integrity — it proves the token wasn't altered — but not confidentiality.

PASETO v4.local applies authenticated encryption: the payload is actually encrypted before being encoded, so without the 32-byte key all you see is ciphertext. That's why v4.local is the right choice when the payload itself should stay private (for example, session data).

Technically yes — both accept a 32-byte symmetric secret — and this playground does exactly that so you can compare formats on even footing.

In production, keep them separate. PASETO enforces key separation between local (encryption) and public (signing) keys, so a key trained for one purpose can't be reused for the other. The shared secret for an HMAC JWT should always be long, random, and high-entropy (32+ bytes).

Choose PASETO v4.local when the payload itself must stay confidential (encrypted session data, sensitive claims) or when you want the stronger, forced-choice crypto defaults that eliminate JWT's algorithm-confusion attacks.

Choose JWT HS256 when you need the broadest ecosystem support, when the payload is non-sensitive, and when a shared secret on a single trust boundary is acceptable. Real-world stacks often use an asymmetric JWT (RS256/ES256) for public cross-service verification, and reach for PASETO v4.local for anything that should be sealed.