iOS developer & learning

JWT generator

Write the claims, choose an algorithm and a secret or key, and get a signed JSON Web Token that is decoded and verified again on the spot.

Signing runs in this tab with your browser's WebCrypto. The secret or private key is never sent anywhere, never saved and never put in the page address.

    Signed token

    Copy token, open the JWT decoder
    Times in the claims
      Round trip: the token decoded again
      Runs in your browser. Nothing you type or open is uploaded. Free to use, no account. More iOS developer tools 
      How to create a JWT
      1. Pick the algorithm your verifier expects. The header's alg follows your choice, and if you type a different supported value into the header, the algorithm switches to match, so the token is never signed with one algorithm while its header names another. You can add a kid so the verifier knows which key to use.
      2. Write the claims as JSON. Use the buttons to set iat to now, exp to a lifetime such as 15m, 1h or 7d, nbf and a random jti.
      3. For HS256, HS384 or HS512, enter the shared secret or generate a random one. For the other algorithms, paste a private key, open a key file or generate a key pair.
      4. The token is signed as you type. The page then decodes it again and checks the signature with the matching key, so you know it verifies before you use it.
      Which algorithm to choose
      • HS256: one shared secret signs and verifies. Simple when the same service issues and checks tokens; every verifier can also forge tokens, so don't share the secret with third parties.
      • RS256: the most widely supported public-key option (OAuth and OpenID Connect providers default to it). The private key signs, anyone with the public key verifies. Keys must be at least 2048 bits.
      • PS256: RSA with PSS padding, the more modern RSA scheme. Signatures differ every time, which is expected.
      • ES256: short keys and short signatures on the P-256 curve. Apple uses it for APNs and App Store Connect API tokens. ES384 and ES512 use P-384 and P-521.
      • EdDSA (Ed25519): fast, small and deterministic. Check that your verifier supports it; older libraries don't. RFC 9864 renamed it Ed25519 in 2025.
      Keys this page reads
      • PKCS#8 PEM (-----BEGIN PRIVATE KEY-----), which is also the format of Apple's .p8 keys.
      • PKCS#1 RSA keys (-----BEGIN RSA PRIVATE KEY-----) and SEC1 EC keys (-----BEGIN EC PRIVATE KEY-----), converted in the tab.
      • A private JWK, or the first key of a JWKS. A public key, a certificate or a passphrase-protected key is explained instead of failing silently.
      • The key must match the algorithm: an RSA key can't sign ES256, and ES256 needs a P-256 key. The page names the algorithm that fits the key you pasted.
      Secrets for HS256, HS384 and HS512
      RFC 7518 says an HMAC key must be at least as long as the hash: 32 bytes for HS256, 48 for HS384 and 64 for HS512. A short or guessable secret can be found offline from a single token, because anyone holding a token can try guesses against its signature without contacting your server. The page warns about short secrets, repeated characters, single words and secrets from tutorials, including the sample secret that ships with popular JWT debuggers.
      Generate a random secret here or with openssl rand -base64 64, keep it in your secret manager, and rotate it if it ever appears in a log or a repository.
      Claims and times
      JWT times are NumericDates: whole seconds since 1 January 1970 UTC, not milliseconds. The page shows each iat, nbf and exp as a date and warns when a value looks like milliseconds, when the token has already expired, or when it can never be valid.
      Numbers larger than 2^53 are signed exactly as you typed them, but many libraries round them when they parse the token, so the page suggests strings for long IDs. A key written twice in one object is flagged too, because decoders disagree about which value wins.
      Related tools
      Paste a token into the JWT decoder to read and verify tokens you receive. For Apple push notifications, the APNs JWT generator builds the ES256 provider token from your .p8 key with the right claims.
      Private by design
      Privacy
      Signing, key generation and verification run in this browser tab with WebCrypto. This tool makes no network request: your secret, private key, header and claims aren't sent anywhere, aren't saved in the browser and never go in the page address. Only the chosen algorithm and the lifetime settings are remembered as preferences. Close the tab to forget a generated key pair.
      This page also shows Google ads, which can use cookies. Privacy and cookies explains how.
      Link to this tool
      Found it useful? You're welcome to link to it from your README, docs or blog.
      Questions
      How do I generate a JWT token online safely?
      Use a generator that signs in your browser and sends nothing, like this one: the secret or private key stays in the tab. For production tokens, prefer a test key or a key you can rotate, and never paste a live signing key into a site whose code you can't check.
      What secret length should I use for HS256?
      At least 32 random bytes (256 bits), which is what RFC 7518 requires for HS256; 48 bytes for HS384 and 64 for HS512. A random Base64 string of 43 characters or more covers HS256. Words and phrases are too easy to guess offline.
      Why does my JWT fail to verify?
      Common causes: the verifier expects a different alg, the secret is encoded differently (text versus Base64), the public key doesn't belong to the private key, exp or nbf are in milliseconds instead of seconds, or the token has expired. The round trip on this page shows whether the token itself verifies.
      Should I use RS256 or ES256?
      Both are public-key algorithms. RS256 has the widest library support; ES256 has much smaller keys and signatures and is what Apple uses for APNs and App Store Connect. Choose what your verifier supports.
      Can I create a JWT without a secret (alg none)?
      Not here. Unsigned tokens are rejected by any correctly configured verifier, and accepting them has caused real security bugs. Use a test secret instead.
      From the same developer
      More iOS developer tools
      All 36 iOS developer tools 
      Also try: Hash generator