Ce face de fapt un decodor JWT
Un JSON Web Token (JWT) arată ca un șir lung și opac de caractere aleatorii, dar nu este criptat și nu este un cifru secret. Este un container compact, sigur pentru URL-uri, care transportă date structurate între două părți. Lipește un token în decodorul de mai sus și acesta desface acel șir, arătându-ți JSON-ul real din interior — metadatele, revendicările (claims), cui îi este destinat token-ul și când expiră. Totul se întâmplă chiar în browserul tău. Token-ul nu este niciodată încărcat, înregistrat sau trimis nicăieri, ceea ce contează enorm atunci când ceea ce inspectezi este o credențială de sesiune activă.

Trei părți, două puncte
Orice JWT bine format este format din trei string-uri codificate Base64url, unite prin puncte: header.payload.signature. Acel singur caracter punct este modul în care parserele știu unde se termină o secțiune și unde începe următoarea, motiv pentru care un token cu un număr greșit de puncte este respins înainte ca orice altceva să fie citit.
Header-ul este un obiect JSON minuscul care descrie token-ul în sine. Aproape întotdeauna conține typ (tipul, de obicei JWT) și alg — algoritmul de semnare, precum HS256 (HMAC cu SHA-256) sau RS256 (RSA cu SHA-256). Header-ul îi spune unui verificator exact cum a fost produsă semnătura.
Payload-ul este partea care contează cel mai mult pentru majoritatea oamenilor. Este un alt obiect JSON care conține claims (revendicări) — afirmații despre utilizator și token. Specificația sortează revendicările în înregistrate (nume standard, rezervate), publice și private (nume personalizate pe care le inventezi pentru propria aplicație). Decodificarea payload-ului este ceea ce dezvăluie cine este autentificat, ce rol deține și când expiră sesiunea sa.
Semnătura este sigiliul criptografic. Este calculată peste header-ul și payload-ul codificate, folosind algoritmul din header plus o cheie secretă sau privată. Deoarece acoperă ambele celelalte secțiuni, orice modificare a header-ului sau payload-ului — chiar și un singur caracter — o invalidează.
Revendicările pe care le vei vedea cel mai des
Revendicările înregistrate sunt nume scurte, de trei litere, definite de RFC 7519, astfel încât sisteme diferite să poată interopera. Câteva apar aproape peste tot:
iss— issuer (emitent): cine a creat token-ul (serverul tău de autentificare sau furnizorul de identitate).sub— subject (subiect): principalul despre care este token-ul, de obicei un ID de utilizator stabil.aud— audience (audiență): destinatarul căruia îi este destinat token-ul. Un API ar trebui să respingă token-uri a căror audiență nu este el însuși.exp— expiration time (timp de expirare): un timestamp Unix după care token-ul nu mai trebuie acceptat.iat— issued at (emis la): timestamp-ul Unix la care token-ul a fost creat.
S-ar putea să întâlnești și nbf (not before) și jti (un ID unic de token). Timestamp-urile sunt exprimate în secunde de la 1970, în UTC, motiv pentru care un decodor care le afișează ca date lizibile pentru oameni îți scutește efortul mental de a verifica dacă un token a expirat deja.
Decodificarea nu înseamnă verificare — aceasta este partea care încurcă lumea
Această distincție este cel mai important lucru de înțeles despre JWT-uri. Decodificarea înseamnă citirea conținutului: nu necesită nicio cheie, iar oricine deține token-ul o poate face, deoarece Base64url este o codificare, nu o criptare. Verificarea înseamnă dovedirea faptului că token-ul este autentic și neatins — recalcularea semnăturii cu cheia secretă sau publică corectă și confirmarea că se potrivește.
Acest instrument decodifică. Îți arată ce spune token-ul, nu dacă token-ul este demn de încredere. Un token ar putea fi falsificat, expirat sau reluat (replay) și tot s-ar decodifica într-un JSON perfect curat aparent. Nu lua niciodată o decizie de autorizare bazându-te doar pe revendicările decodificate. În producție verifici semnătura pe server, verifici exp și confirmi că iss și aud se potrivesc cu ce te aștepți — folosind o bibliotecă verificată, niciodată o comparație de string-uri făcută manual.

Un payload nu este un seif
Deoarece payload-ul este doar codificat Base64url, este lizibil de către oricine interceptează token-ul. Tratează tot conținutul lui ca fiind public. Nu pune parole, numere complete de carduri de credit, chei secrete sau orice date personale sensibile în revendicările JWT — dacă îl poți decodifica aici dintr-un singur clic, la fel poate face oricine altcineva care obține o copie. Semnătura protejează împotriva modificării, niciodată împotriva citirii. Dacă chiar ai nevoie să ascunzi conținutul payload-ului, asta este o treabă pentru JWE (token-uri criptate), o specificație complet diferită.
Confidențialitate și instrumente înrudite
Inspectarea unui token este un act sensibil, așa că acest decodor rulează integral pe partea de client — parsarea este JavaScript simplu în tab-ul tău și nimic nu părăsește dispozitivul tău. Lipirea unui token de sesiune într-un instrument bazat pe server înseamnă predarea unei credențiale active unui terț, exact ce ar trebui să eviți. Pentru codificarea care stă la baza tuturor acestora, vezi instrumentul nostru Base64 și explorează restul instrumentelor pentru dezvoltatori pentru mai multe utilitare care rulează pe dispozitiv.
Întrebări frecvente
Un JWT este criptat?
Nu. Un JWT standard este codificat Base64url, nu criptat. Oricine deține token-ul poate citi header-ul și payload-ul. Folosește JWE dacă ai nevoie ca conținutul să fie ascuns.
Acest instrument verifică semnătura?
Nu. Doar decodifică și afișează header-ul și payload-ul. Verificarea semnăturii necesită cheia secretă sau publică a emitentului și ar trebui făcută pe serverul tău.
Este sigur să-mi lipesc token-ul aici?
Da. Decodificarea rulează integral în browserul tău, folosind JavaScript local. Token-ul nu este niciodată încărcat, stocat sau trimis către vreun server.
Ce înseamnă iss, sub, aud, exp și iat?
Sunt revendicări înregistrate: emitent, subiect, audiență, timp de expirare și timp de emitere. Cele trei legate de timp folosesc timestamp-uri Unix exprimate în secunde.
Pot avea încredere în revendicările afișate după decodificare?
Nu de sine stătător. Revendicările decodificate pot proveni dintr-un token falsificat sau expirat. Verifică întotdeauna semnătura și verifică expirarea pe server înainte de a avea încredere în ele.
De ce token-ul meu are trei părți separate prin puncte?
Acestea sunt header-ul, payload-ul și semnătura, fiecare codificate Base64url și unite prin puncte. Punctele le spun parserelor unde începe și unde se termină fiecare secțiune.
