JWT-parser

Dekod og inspiser JSON Web Tokens (JWT) med sanntidsvalidering. Se header-, payload- og signaturinformasjon sikkert i nettleseren.

Definisjon: Et JSON Web Token består av tre Base64URL-kodede deler — header, payload, signatur — forbundet med punktum. Headeren angir signaturalgoritmen, og signaturen verifiseres med nøkkelmaterialet for algoritmen i henhold til RFC 7519.

IETF RFC 7519 Sist oppdatert: 2026-09

Slik bruker du JWT-parseren

# Dokumenttittel ## Introduksjon Dette er et avsnitt med **fet** og *kursiv* tekst. ### Nøkkelfunksjoner - Enkel å bruke - Rask behandling - Profesjonelt resultat ## Konklusjon Avsluttende tanker og sammendrag.

Lim inn token

Paste your JWT token in the input area

# Dokumenttittel ## Introduksjon Dette er et avsnitt med **fet** og *kursiv* tekst. ### Hovedpunkter - Første punkt - Andre punkt - Tredje punkt ## Konklusjon Et annet avsnitt her.

Automatisk dekoding

Token automatically decodes on paste

« Forrige

Undersøk delene

View header, payload, and signature data

0 bilder valgt

Sjekk status

Kontroller tokenets gyldighet og utløpstid

Å forstå JWT-tokener

Hva er en JWT?

Et JSON Web Token (JWT) er en kompakt og URL-sikker måte å representere claims som overføres mellom to parter. Det består av tre deler — header, payload og signatur — adskilt med punkter og base64url-kodet.

  • • Header: Contains token type and signing algorithm
  • • Payload: Contains claims or user data
  • • Signature: Verifies token wasn't tampered with
  • • Stateless: No server-side session storage needed

Hvorfor parse JWT-er?

JWT-parsing er avgjørende for å feilsøke autentiseringsproblemer, verifisere tokeninnhold, kontrollere utløpstider og forstå hvilke data som overføres i tokens.

  • • Debugging: Inspect token contents during development
  • • Security: Verify token structure and claims
  • • Expiration: Check token validity period
  • • Development: Understand authentication flow

Referanse for standard JWT-claims

Registrerte claim-navn definert av RFC 7519 som du vil se i nesten enhver token-nyttelast.

Claim Fullt navn Betydning
issUtstederHvem som opprettet og signerte tokenet
subEmneHvem tokenet gjelder — vanligvis bruker-ID-en
audMålgruppeHvem tokenet er ment for (en klient eller et API)
expUtløpUnix-tidsstempel som tokenet må avvises etter
nbfIkke forUnix-tidsstempel før hvilket tokenet er ugyldig
iatUtstedtUnix-tidsstempel for når tokenet ble opprettet
jtiJWT-IDUnik identifikator, nyttig for tilbakekallingslister

Vanlige JWT-algoritmer

  • • HS256 (HMAC + SHA-256): Symmetrisk — én delt hemmelighet signerer og verifiserer. Enkelt, men alle som har hemmeligheten, kan forfalske tokens.
  • • RS256 (RSA + SHA-256): Asymmetrisk — privat nøkkel signerer, offentlig nøkkel verifiserer. Standardvalget for distribuerte systemer.
  • • ES256 (ECDSA + SHA-256): Asymmetrisk som RS256, men med mye kortere signaturer — et godt moderne standardvalg.
  • • none: Usignert token. Må avvises av enhver seriøs verifikator; historisk kilden til kritiske bypass-sårbarheter.

Sikkerhetsmerknader

  • • Lim aldri inn produksjonstokens i ukjente verktøy. Denne parseren kjører helt i nettleseren din (sjekk: den fungerer offline), men det gjelder ikke alle nettsteder.
  • • En JWT er ikke kryptert. Nyttelasten er bare base64url-kodet — alle som har tokenet kan lese den. Lagre aldri hemmeligheter i claims.
  • • Dekoding er ikke verifisering. En struktur som ser gyldig ut, sier ingenting om signaturen. Verifisering krever nøkkelen, som aldri forlater autentiseringsserveren din.
  • • Sjekk exp på serversiden. Å avvise utløpte tokens er verifikatorens jobb, ikke klientens.

Når utviklere bruker en JWT-parser

Feilsøke 401- og 403-svar

Sjekk om tokenet faktisk inneholdt de forventede scopes, rollene eller utløpet før du skylder på serveren.

Undersøke OAuth- og OIDC-tokener

Dekoder et id_token eller access_token og bekreft at iss, aud og sub stemmer med programkonfigurasjonen din.

Støtte og feilsøking

Sjekk fra et skjermbilde hvilke claims en bruker faktisk mottok, uten å sette opp noen lokale verktøy.

Lære hvordan JWT-er fungerer

Lim inn eksempeltokens og se hvordan header, payload og signatur henger sammen.

Øyeblikkelig dekoding

Dekoder JWT automatisk ved innliming, med fargekodede deler.

100% privat

All dekoding skjer i nettleseren din. Tokens forlater aldri enheten din.

Helt gratis

Ingen registrering eller grenser. Parse JWT-tokens fritt når som helst.

Vanlige spørsmål om JWT-parser

Er det trygt å lime inn en JWT i dette verktøyet?

Ja. Dekoding kjører helt og holdent i nettleseren din uten nettverkskall — du kan verifisere det ved å koble fra internett og laste siden på nytt. Likevel: lim aldri inn produksjonstokens noe sted, som en generell god vane.

Verifiserer parsing av en JWT signaturen dens?

Nei. Parsing base64url-dekoder kun headeren og payloaden. For å verifisere signaturen trengs signeringsnøkkelen (HMAC-hemmeligheten eller offentlig nøkkel), som bare autentiseringsserveren din har.

Hvorfor kan hvem som helst lese JWT-payloaden min?

JWT-payloader er kodet, ikke kryptert. Enhver som har tokenet kan dekode og lese claimene — det er et bevisst designvalg. Lagre aldri hemmeligheter eller sensitiv data i en JWT-payload.

Hvordan vet jeg når en token utløper?

Sjekk claimen exp — et Unix-tidsstempel som tokenet må avvises etter. Denne parseren fremhever tokenstatus (aktiv, utløpt eller ennå ikke gyldig) automatisk basert på exp og nbf.

Hva er forskjellen mellom HS256 og RS256?

HS256 er symmetrisk: én delt hemmelighet signerer og verifiserer, så alle som kan verifisere tokens kan også forfalske dem. RS256 er asymmetrisk: en privat nøkkel signerer og en offentlig nøkkel verifiserer — tryggere når flere tjenester må validere tokens. Foretrekk RS256 eller ES256 med mindre du har en konkret grunn til ikke å gjøre det.

Tokenhodet mitt sier "alg": "none" — er det et problem?

Det betyr at tokenet er usignert. Det er gyldig JWT-struktur, men en verifikator må aldri godta det: den klassiske JWT-sårbarheten var angripere som satte alg til none for å omgå signaturkontroller. Hvis backenden din godtar usignerte tokens, bør du regne det som en sikkerhetsfeil.