Er det trygt å lime inn JWT her?

Ja. Dekoding skjer helt i nettleseren din - tokenet sendes aldri til noen server. JWT-er er imidlertid legitimasjon - ikke del dem offentlig (i skjermbilder, Stack Overflow-innlegg, etc.) da de kan gi tilgang til kontoene dine.

Verifiserer dette verktøyet JWT-signaturen?

Dette verktøyet dekoder og viser token-innholdet. Signaturverifisering krever den hemmelige nøkkelen (HMAC) eller den offentlige nøkkelen (RSA/ECDSA), som skal forbli på serveren din. Verktøyet viser algoritmen som brukes, men kan ikke bekrefte uten nøkkelen.

Hva betyr standard JWT-påstander?

iss = utsteder, sub = emne (bruker-ID), exp = utløpstid (Unix-tidsstempel), iat = utstedt på, nbf = ikke før, aud = publikum, jti = JWT ID. Egendefinerte krav kan inneholde alle programspesifikke data.

Hvorfor kan hvem som helst dekode en JWT?

JWT-er er kodet, ikke kryptert. Nyttelasten er Base64URL-kodet (ikke kryptert), slik at alle kan lese den. Signaturen forhindrer tukling, ikke lesing. Aldri lagre sensitive data (passord, SSN-er) i JWT-nyttelast.

Hvorfor mangler noen tokens en signatur?

Tokens med alg: ingen har ingen signatur. De er gyldige JWT-er etter spesifikasjoner, men gir ingen autentisitetsgarantier og bør ikke aksepteres i produksjon.

Standard JWT-nyttelast er signert, men ikke kryptert. JWE (JSON Web Encryption, RFC 7516) er et eget format for krypterte tokens. De fleste JWT-er i naturen er JWS (bare signert).

Er tokenet mitt lastet opp til en server?

Nei. Dekoding skjer i nettleseren din; tokenet forlater ikke enheten.

Hvor lange er JWT-er vanligvis?

Alt fra noen hundre til flere tusen tegn. Lengden avhenger av antall og størrelse på krav pluss signaturlengden (som avhenger av algoritmen).

Gratis omformer

JWT-token Dekoder

Dekod JWT (JSON Web Token) header og nyttelast umiddelbart i nettleseren din. Gratis, privat og på klientsiden – ingen data sendes til noen server.

Lim inn JWT-tokenet ditt

Om dette verktøyet

JSON Web Tokens (JWT) er et kompakt, URL-sikkert format for overføring av krav mellom to parter, definert av RFC 7519. En JWT er tre base64url-kodede segmenter atskilt med prikker: header (algoritme og tokentype), nyttelast (krav) og signatur (kryptografisk bevis på autentisitet). Overskriften og nyttelasten er JSON, base64url-kodet for URL-sikkerhet; signaturen bruker en av flere algoritmer (HS256, RS256, ES256 og andre) over den kodede overskriften og nyttelasten.

Å dekode en JWT – dele den opp i segmenter og base64-dekode hver – krever ingen hemmelighet. Alle med symbolteksten kan lese overskriften og nyttelasten. Signaturen kan imidlertid bare verifiseres med hemmeligheten (HMAC) eller den offentlige nøkkelen (asymmetrisk). Avkoding er for inspeksjon; verifisering er det som beviser autentisitet.

Denne dekoderen deler tokenet, base64-dekoder hvert segment, analyserer overskriften og nyttelasten som JSON, og viser resultatet. Den forsøker ikke signaturverifisering fordi det krever den hemmelige eller offentlige nøkkelen, som dekoderen ikke har. Den dekodede utgangen er skrivebeskyttet inspeksjon - nyttig for feilsøking av tokens, men ikke en erstatning for riktig verifisering i applikasjonskoden.

Hvorfor dekode JWT-er

Feilsøking av autentiseringsproblemer involverer nesten alltid inspeksjon av tokens. Et token som ser gyldig ut i koden kan ha feil påstander, en uventet algoritme, et utløpt exp-tidsstempel eller publikumsmismatch. Dekoding av tokenet avslører nøyaktig hva utstederen produserte.

Å inspisere brikker under integreringsarbeid hjelper også. Når du kobler til en tredjeparts API eller identitetsleverandør, forstås de faktiske kravnavnene, formatene og strukturen best ved å dekode prøvetokens i stedet for å stole på dokumentasjon som kan være utdatert.

Slik bruker du det

Lim inn tokenet, få det analyserte innholdet.

Lim inn JWT: Slipp hele tokenet (header.payload.signature) i inndataområdet. Dekoderen godtar tokens med eller uten det valgfrie bærerprefikset.
Inspiser overskriften: Overskriften viser signeringsalgoritmen (alg) og tokentypen (typ). Vanlige algoritmer er HS256, RS256 og ES256. Se etter alg: ingen, som signaliserer et usignert token og sjelden er trygt i produksjon.
Inspiser nyttelasten: The payload contains the claims: iss (issuer), sub (subject), aud (audience), exp (expiration), iat (issued at), and any application-specific claims. Standard tidsstempler er Unix-epokesekunder.
Bekreft separat: Dekoderen bekrefter ikke signaturen. For å sjekke autentisiteten, kjør tokenet gjennom et JWT-bibliotek med den aktuelle hemmelige eller offentlige nøkkelen i applikasjonskoden.

Vanlige brukstilfeller

Feilsøking av utløpte tokenfeil — Dekoding av tokenet avslører exp-kravet. Sammenlign med gjeldende tidspunkt for å bekrefte om utløpet er den faktiske årsaken.
Forstå kravstrukturen til et tredjepartstoken — Identitetsleverandører (Auth0, Okta, Cognito) utsteder tokens med leverandørspesifikke kravoppsett. Dekoding av prøvetokens viser den faktiske strukturen.
Inspiserer tokens under integrering — Når du integrerer SSO- eller OAuth-flyter, hjelper dekoding av tokens ved hvert trinn å bekrefte at dataene er formet som forventet.
Revisjon av tokeninnhold for sensitive data — Tokens er ikke kryptert som standard; nyttelasten er lesbar. Dekoding av eksisterende tokens bidrar til å bekrefte at sensitive data ikke blir inkludert ved et uhell.
Bekrefter publikums- og utstederkrav — Forsvar mot tokenforvirring krever korrekt aud- og isshåndtering. Dekoding av tokens under testing bekrefter at disse påstandene er riktig fylt ut.

Tekniske detaljer

JWT-formatet er tre segmenter forbundet med prikker. Hvert segment er base64url-kodet - den URL-sikre varianten av base64 som bruker - og _ i stedet for + og /, med utfylling noen ganger utelatt. Dekoding krever å angre de URL-sikre erstatningene, utfylling av segmentet og base64-dekoding.

Overskriften og nyttelasten er JSON etter dekoding. Signatursegmentet er binært (rå signaturbytes) og er ikke lesbart for mennesker; det krever at verifiseringsnøkkelen er nyttig.

Vanlige krav definert i RFC 7519: iss (utsteder), sub (emneidentifikator), aud (publikum), exp (utløp som Unix-epokesekunder), nbf (ikke-før-tidsstempel), iat (utstedt-til-tidsstempel), jti (unikt token-ID). Applikasjonsspesifikke krav kan vises med et hvilket som helst navn.

Beste praksis

Stol aldri på en ubekreftet JWT — Avkoding avslører bare innholdet; det beviser ikke autentisitet. Bekreft alltid signaturen med riktig nøkkel i applikasjonskoden før du stoler på påstandene.
Se etter alg: ingen — Tokens med alg: ingen har ingen signatur. Applikasjonskode som godtar dem er sårbar for forfalskning. Krev alltid en spesifikk algoritme i bekreftelseskonfigurasjonen.
Vær forsiktig med sensitive data i nyttelast — JWT-nyttelast kan leses av alle med token. Krypter nyttelasten (bruk JWE) hvis den inneholder data som må være hemmelige.
Valider exp før behandling — Et utløpt token bør avvises selv om signaturen er gyldig. JWT-biblioteker sjekker vanligvis exp automatisk; bekrefte at biblioteket ditt gjør det.

Ofte stilte spørsmål

Er det trygt å lime inn JWT her?: Ja. Dekoding skjer helt i nettleseren din - tokenet sendes aldri til noen server. JWT-er er imidlertid legitimasjon - ikke del dem offentlig (i skjermbilder, Stack Overflow-innlegg, etc.) da de kan gi tilgang til kontoene dine.
Verifiserer dette verktøyet JWT-signaturen?: Dette verktøyet dekoder og viser token-innholdet. Signaturverifisering krever den hemmelige nøkkelen (HMAC) eller den offentlige nøkkelen (RSA/ECDSA), som skal forbli på serveren din. Verktøyet viser algoritmen som brukes, men kan ikke bekrefte uten nøkkelen.
Hva betyr standard JWT-påstander?: iss = utsteder, sub = emne (bruker-ID), exp = utløpstid (Unix-tidsstempel), iat = utstedt på, nbf = ikke før, aud = publikum, jti = JWT ID. Egendefinerte krav kan inneholde alle programspesifikke data.
Hvorfor kan hvem som helst dekode en JWT?: JWT-er er kodet, ikke kryptert. Nyttelasten er Base64URL-kodet (ikke kryptert), slik at alle kan lese den. Signaturen forhindrer tukling, ikke lesing. Aldri lagre sensitive data (passord, SSN-er) i JWT-nyttelast.
Hvorfor mangler noen tokens en signatur?: Tokens med alg: ingen har ingen signatur. De er gyldige JWT-er etter spesifikasjoner, men gir ingen autentisitetsgarantier og bør ikke aksepteres i produksjon.
Er JWT-er kryptert?: Standard JWT-nyttelast er signert, men ikke kryptert. JWE (JSON Web Encryption, RFC 7516) er et eget format for krypterte tokens. De fleste JWT-er i naturen er JWS (bare signert).
Er tokenet mitt lastet opp til en server?: Nei. Dekoding skjer i nettleseren din; tokenet forlater ikke enheten.
Hvor lange er JWT-er vanligvis?: Alt fra noen hundre til flere tusen tegn. Lengden avhenger av antall og størrelse på krav pluss signaturlengden (som avhenger av algoritmen).

JWT-token Dekoder

Relaterte verktøy

URL-koder / Dekoder

Base64-koder / Dekoder

JSON-formater & Validator

XML-formater & Validator

Om dette verktøyet

Hvorfor dekode JWT-er

Slik bruker du det

Vanlige brukstilfeller

Tekniske detaljer

Beste praksis

Ofte stilte spørsmål

Related Articles

Essential Developer Tools: JSON, Base64, RegEx, and More

Hashing, Encryption, and Encoding Explained: A Developer's Security Guide

Spreadsheet & Data Conversion Guide: Excel, CSV, JSON, and More

Why Browser-Based Tools Are the Future: No Installs, No Uploads, No Risk