Why use TokenSmith?
JWT decoding, hashing, and signature verification happen in your browser — nothing you paste here reaches any server.
Your tokens never leave the browser
JWTs frequently carry session credentials, user roles, and API keys. Pasting them into a server-side tool sends your secrets through infrastructure you don't control. Every operation here runs locally and is discarded when you close the tab.
No account, no history stored
Some token tools offer to "save" your decoded history — which means storing credentials on their servers. This tool has no server and keeps no log. Your token, your device, your session.
Cryptographic operations use Web Crypto
HMAC signing and TOTP generation use the browser's built-in Web Crypto API — the same standard that powers HTTPS connections. Tools that rely on JavaScript's Math.random() instead produce outputs that are technically predictable, which matters when you're verifying signatures.
Output is exactly what's in the token
Some tools reformat decoded payloads or inject tracking markup into exported results. The output here shows the raw header, payload, and signature status — nothing added, nothing repackaged.
JWT anatomy: header, payload, signature
A JSON Web Token is three Base64url-encoded segments separated by dots: header.payload.signature. The header names the signing algorithm (HS256, RS256, ES256). The payload carries claims — registered ones like iss, sub, exp, and iat, plus any application-specific fields. The signature binds the first two segments together so the receiver can verify they have not been altered. TokenSmith decodes both header and payload instantly, flags expired tokens with a clear warning, and shows the time remaining until expiry for live ones. Decoding is always safe — the signature is displayed but not verified here.
HMAC: authenticating messages without encryption
HMAC (Hash-based Message Authentication Code) combines a secret key with a message through a hash function to produce a short authentication tag. The recipient recomputes the tag using the same key — matching tags prove the message arrived intact and came from someone who knows the secret. HMAC authenticates but does not encrypt: the message stays readable. Common uses include webhook signature verification (Stripe, GitHub, and Twilio all use HMAC-SHA256), JWT signing with HS256/HS384/HS512, and API request signing. TokenSmith outputs HMAC results as hex or Base64 for all three SHA variants.
TOTP: how time-based one-time passwords work
TOTP (RFC 6238) generates a 6-digit code from a shared secret and the current 30-second time window using HMAC-SHA1. Your authenticator app and the server compute the same code independently — no network call required. Because the code changes every 30 seconds, an intercepted one is useless after its window expires. TOTP is the mechanism behind Google Authenticator, Authy, and hardware tokens like YubiKey. The shared secret embedded in the QR code you scan is a Base32 byte sequence. TokenSmith generates live codes that refresh on the timer — useful for testing 2FA integrations without reaching for your phone.
Hash functions: SHA-256, SHA-512, and when to use each
A cryptographic hash function maps any input to a fixed-length digest — SHA-256 always produces 64 hex characters regardless of whether the input is a single space or a gigabyte of text. Hashes are one-way: the digest reveals nothing useful about the input without exhaustive brute force. SHA-256 and SHA-512 are the current standard for integrity checks, digital signatures, and as building blocks in password-hashing algorithms like bcrypt and PBKDF2. MD5 and SHA-1 are broken for collision resistance and are retired for security purposes, but still appear in legacy checksums, cache-busting keys, and ETags where collision resistance does not matter.
UUIDs, ULIDs, and database-friendly identifiers
UUID v4 generates 128 bits of randomness in the familiar xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx format — the collision space is large enough that it can be used as a distributed primary key without coordination. UUID v7 adds a millisecond-precision timestamp prefix, making identifiers monotonically increasing and therefore friendly to B-tree indexes that insert faster when keys arrive in order. ULID encodes a 48-bit timestamp plus 80 bits of randomness into a 26-character Crockford Base32 string with no dashes, making it URL-safe, case-insensitive, and sortable. TokenSmith generates all three and supports bulk output for seeding test datasets.
Unix timestamps: conversion and common pitfalls
A Unix timestamp counts seconds elapsed since 1970-01-01 00:00:00 UTC. It has no time zone — it is always UTC; converting to a human-readable date is a formatting step performed by the client. Common pitfalls: JavaScript's Date works in milliseconds (multiply or divide by 1000 when crossing the API boundary), MySQL's UNIX_TIMESTAMP() returns seconds, and systems that store Unix time as a signed 32-bit integer overflow on 2038-01-19. TokenSmith converts in both directions, shows the equivalent in multiple time zones simultaneously, and makes it easy to read any timestamp from an API response or log file without mental arithmetic.
What a JWT is and why everything uses them now
A JWT is a small packet of information your browser receives when you log in to most modern apps. Instead of sending your password with every request, the server gives you this token and you present it each time — like a wristband at a concert. Paste one here and you can read exactly what’s inside: your user ID, when it expires, what permissions you have. The token is not encrypted — anyone who has it can read it — but it can’t be secretly changed, because the third segment is a tamper-proof seal. If the seal doesn’t match, the server rejects it.
HMAC: verifying a message came from who it claims
When GitHub, Stripe, or Twilio sends a webhook to your server, how do you know it’s actually from them and not someone pretending? They use HMAC — a kind of digital wax seal. They take their message, mix it with a secret key only they and you know, and produce a short fingerprint. Your server does the same math with the same key. If the fingerprints match, the message is genuine. If they don’t, something tampered with it in transit. You never share the key publicly — it stays between you and the service.
How those 6-digit login codes actually work
When you enable two-factor authentication on an account, the site gives you a secret key — usually as a QR code you scan with an authenticator app. Every 30 seconds, your phone and the server independently run the same math on that secret key and the current time, and they both arrive at the same 6-digit number. If someone steals the code, it’s useless 30 seconds later. TokenSmith can generate those codes too — useful when you’re building 2FA into your own app and need to test it without reaching for your phone.
What a hash is and why you can’t undo it
A hash function is a one-way blender. Put anything in — a single word, an entire file — and it produces the same fixed-length string every time. Change one character in the input and the output looks completely different. You can’t run it backwards. This is how sites store your password without ever keeping your actual password: they hash it, store the hash, and when you log in they hash what you typed and compare results. It’s also how you verify a downloaded file is what it claims to be — the site publishes the expected hash, you run the file through the same function, and check that they match.
UUIDs: why apps generate their own IDs instead of counting up
Using sequential numbers (1, 2, 3...) as database IDs breaks down when multiple servers generate records simultaneously — two servers would both create record number 42. A UUID is a 128-bit random number virtually guaranteed to be unique even without coordination between systems. Newer versions (v7 and ULID) add a timestamp at the front so IDs sort in the order they were created — important because databases insert new rows significantly faster when keys arrive in sequence.
Unix timestamps: the number every computer uses for time
Almost every computer system that records when something happened uses Unix time — a single number counting the seconds since January 1, 1970. It has no time zone, no format ambiguity, and it’s trivially easy to compare or calculate with. If you’ve ever seen a large number like 1717632000 in an API response and wondered what it meant, paste it here to convert it to a readable date. The most common source of confusion: JavaScript uses milliseconds instead of seconds, so JavaScript timestamps are 1000 times larger than what most other systems produce.