JWT Decoder

Avkoda och inspektera JSON Web Tokens

Prova ett exempel

JWT-token

Körs lokalt · Säkert att klistra in hemligheter
Prova också:JWT Encoder

Vad är en JWT (JSON Web Token)?

En JSON Web Token (JWT) är ett kompakt, URL-säkert tokenformat definierat i RFC 7519. Det kodar en uppsättning claims som ett JSON-objekt och signerar det sedan — och krypterar det valfritt — så att mottagaren kan verifiera att data inte har manipulerats. JWT är de facto-standard för tillståndslös autentisering i REST API:er, single sign-on-system och mikroservicebehörighet.

JWT-anatomi: Header · Payload · Signature

Varje JWT består av tre base64url-kodade segment separerade av punkter. Header och Payload är vanlig JSON — läsbar av vem som helst — medan Signature är ett kryptografiskt värde som bara kan verifieras med rätt nyckel.

Kodat token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HeaderPayloadSignature
Header
json
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
json
{
  "sub":  "user123",
  "name": "Alice",
  "role": "admin",
  "iat":  1717200000,
  "exp":  1717203600
}

Varför använda en JWT-avkodare?

Råa JWT ser ut som slumpmässig text. Det här verktyget renderar omedelbart Header och Payload som formaterad JSON så att du kan inspektera claims, kontrollera utgångstider och granska algoritmval utan att skriva en enda rad kod.

🔍
Omedelbar claim-inspektion
Se varje claim i Payload — sub, iss, aud, exp, anpassade roller, behörigheter — formaterad och läsbar med ett klick.
🔓
Ingen hemlig nyckel behövs
Header och Payload är offentliga; bara Signature kräver hemligheten. Det här verktyget avkodar båda utan din signeringsnyckel.
⏱️
Analys av utgångstid och tidsstämplar
Unix-tidsstämplar (exp, iat, nbf) konverteras automatiskt till läsbara datum så att du omedelbart kan se om ett token har gått ut.
🔒
Körs helt i din webbläsare
Allt bearbetas lokalt — inga tokendata skickas till någon server. Säkert att använda med produktionstoken vid felsökning.

Referens för standard-JWT-claims

RFC 7519 definierar sju registrerade claimnamn. Dessa är inte obligatoriska, men deras användning rekommenderas starkt för interoperabilitet. Du kan lägga till anpassade claims i Payload.

ClaimBeskrivningTyp
issUtfärdareIdentifierar vem som utfärdade token — t.ex. URL:en för din autentiseringsserver eller applikationsnamnet.string
subÄmneIdentifierar det subjekt som JWT handlar om — vanligtvis ett användar-ID eller tjänstkonto.string
audMålgruppIdentifierar de avsedda mottagarna. Den mottagande parten måste verifiera att detta matchar deras identifierare.string | string[]
expUtgångstidUnix-tidsstämpel efter vilken token inte får accepteras. Ange alltid detta för att begränsa skadan från ett stulet token.number
nbfInte föreUnix-tidsstämpel innan vilken token inte får accepteras. Användbart för att schemalägga framtidsdaterade token.number
iatUtfärdat vidUnix-tidsstämpel då token utfärdades. Används för att beräkna tokens ålder.number
jtiJWT IDEn unik identifierare för token. Möjliggör återkallande genom att lagra och kontrollera använda JTI-värden på serversidan.string

JWT-signeringsalgoritmer

Header-claimen alg deklarerar vilken algoritm som signerade token. Valet påverkar säkerhet, prestanda och om tredjepartstjänster kan verifiera token utan den privata nyckeln.

AlgoritmFamiljNyckeltypAnteckningar
HS256HMACSymmetricVanligast. Delad hemlighet — vem som helst med hemligheten kan signera och verifiera.
HS384HMACSymmetricStarkare HMAC-variant; måttlig prestandakostnad.
HS512HMACSymmetricStarkaste HMAC-varianten.
RS256RSAAsymmetricDen mest använda asymmetriska algoritmen (Google, Auth0, Okta). Offentlig nyckel verifierar utan privat nyckel.
RS384RSAAsymmetricRS-variant med högre säkerhet.
RS512RSAAsymmetricStarkaste RS-varianten.
ES256ECDSAAsymmetricElliptisk kurva — kortare signaturer än RSA, populär på mobil och IoT.
PS256RSA-PSSAsymmetricRSA-PSS: modernare och säkrare än PKCS1v1.5-baserade RS256.
noneIngen signatur — kritiskt farligt. Acceptera aldrig token med alg: none i produktion.

Säkerhetsöverväganden

Att avkoda en JWT är alltid säkert. Att lita på en JWT utan korrekt signaturverifiering är det inte. Ha dessa regler i åtanke när du använder token i din applikation.

Alltid säkert
  • Avkoda och inspektera en JWT i utvecklarverktyg eller det här verktyget
  • Använd exp, iat och nbf för att förstå tokens livstid
  • Logga Payload-claims för felsökning (uteslut känslig personlig information)
  • Läs alg-headern för att förstå hur token signerades
Gör aldrig detta
  • Lita på claims i Payload utan att verifiera signaturen på serversidan
  • Acceptera token med alg: none — det betyder ingen signatur alls
  • Lagra åtkomsttoken i localStorage i säkerhetskritiska applikationer (föredra httpOnly-cookies)
  • Ange exp långt in i framtiden för token som bär känsliga behörigheter

Vanliga användningsfall

Felsökning av autentiseringsflöden
Klistra in ett token från webbläsarens nätverksflik för att inspektera claims, kontrollera inbäddade roller och verifiera utgångstid utan att röra produktionskoden.
Inspektera tredjepartstoken
Läs snabbt token från Google, Auth0, Okta eller Azure AD för att se vilka claims din leverantör inkluderar och jämföra dem med ditt förväntade schema.
API-utveckling och testning
När du skriver eller testar API-endpoints, avkoda auktoriseringsheadern för att bekräfta att din tokengenereringslogik ställer in rätt värden för sub, aud och scope.
Mikroservicebehörighet
I service mesh validerar varje tjänst JWT från uppströms anropare. Avkoda token för att spåra vilken tjänst som utfärdade token och vilka behörigheter den hävdar.
Support och incidentrespons
När en användare rapporterar ett autentiseringsfel, avkoda deras token för att kontrollera om det har gått ut, om målgruppen är fel eller om ett obligatoriskt claim saknas.
Säkerhetsrevision
Granska JWT-användning i tjänster genom att kontrollera algoritmval, utgångstidsfönster och om känslig data av misstag lagras i den okrypterade Payload.

Avkoda JWT i kod

Header och Payload är base64url-kodade — vänd bara på kodningen. Base64url ersätter + med - och / med _, och utelämnar = som utfyllnad. Bara Signature kräver den hemliga nyckeln.

JavaScript (browser)
function decodeJWT(token) {
  const [, payload] = token.split('.')
  const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
  return JSON.parse(json)
}
Node.js
const [, payload] = token.split('.')
const decoded = JSON.parse(
  Buffer.from(payload, 'base64url').toString()
)
Python
import base64, json

def decode_jwt(token):
    payload = token.split('.')[1]
    padding = '=' * (-len(payload) % 4)
    return json.loads(base64.urlsafe_b64decode(payload + padding))
CLI (bash + jq)
TOKEN="eyJhbGc..."
echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .

Vanliga frågor

Kan jag avkoda en JWT utan den hemliga nyckeln?
Ja. Header och Payload för en JWT är enkelt base64url-kodad JSON — inte krypterad. Vem som helst kan avkoda och läsa dem. Hemligheten (eller privat nyckel för RS/ES-algoritmer) behövs bara för att verifiera signaturen, vilket bekräftar att token inte manipulerats.
Innebär avkodning av en JWT att signaturen har verifierats?
Nej. Avkodning läser bara claims. Verifiering är ett separat steg som kontrollerar den kryptografiska signaturen med rätt nyckel. Verifiera alltid signaturen innan du litar på claims i din applikation.
Vad är skillnaden mellan HS256 och RS256?
HS256 använder en enda symmetrisk hemlighet delad mellan utfärdare och verifierare — vem som helst med hemligheten kan skapa och verifiera token. RS256 använder ett asymmetriskt nyckelpar: privat nyckel signerar, offentlig nyckel verifierar. Med RS256 kan du distribuera den offentliga nyckeln så att externa tjänster kan verifiera token utan möjlighet att förfalska dem.
Varför misslyckas ibland base64-avkodning?
JWT använder base64url-kodning, som använder - istället för + och _ istället för /, och utelämnar = som utfyllnadstecken. Standardavkodare för base64 kräver + och / och kan kräva utfyllnad. Lägg till utfyllnaden (fyll till en multipel av 4 med =) och byt tecknen innan du avkodar manuellt.
Är det säkert att klistra in ett produktions-JWT i det här verktyget?
Ja — det här verktyget körs helt i din webbläsare och skickar inga data till någon server. Var dock uppmärksam på vem som kan se din skärm eller webbläsarhistorik. För mycket känsliga token, avkoda dem lokalt i din terminal.
Vad betyder alg: none och är det farligt?
alg: none innebär att token inte har någon kryptografisk signatur — vem som helst kan skapa ett token med godtyckliga claims och ange alg till none. Vissa tidiga JWT-bibliotek accepterade dessa token, vilket skapade en kritisk sårbarhet. Ett säkert JWT-bibliotek avvisar alltid token med alg: none om det inte uttryckligen konfigurerats på annat sätt. Inaktivera aldrig den här kontrollen.