jsonwebtoken and jwt-decode are both utilities for working with JSON Web Tokens (JWTs), but they serve fundamentally different roles in an application architecture. jsonwebtoken is a comprehensive library capable of both signing (creating) and verifying tokens, typically used in backend Node.js environments where a secret key is safely stored. jwt-decode, on the other hand, is a lightweight, frontend-focused utility designed solely to decode the payload of a token without verifying its signature. It allows browser-based applications to read token data (like user roles or expiration) without needing access to the secret key, making it ideal for client-side logic like conditional UI rendering or silent refresh checks.
When implementing authentication in modern web applications, developers often encounter two popular npm packages: jsonwebtoken and jwt-decode. While both deal with JSON Web Tokens (JWTs), confusing their roles can lead to severe security flaws or unnecessary bloat. Let's break down exactly what each tool does, where it belongs in your stack, and how to use them correctly.
The most critical distinction is cryptographic capability. jsonwebtoken is a full-featured crypto library. It can sign data to create a token and verify a token's signature to ensure it hasn't been tampered with. This requires a secret key.
jwt-decode is a read-only tool. It simply parses the base64url-encoded string to reveal the JSON payload inside. It performs no cryptographic verification. It assumes the token is valid and just shows you what's inside.
// jsonwebtoken: Creates and signs a token (Backend only)
const jwt = require('jsonwebtoken');
const secret = 'my_super_secret_key'; // Never expose this to the client
const token = jwt.sign({ userId: 123, role: 'admin' }, secret, { expiresIn: '1h' });
// Output: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
// jwt-decode: Reads the payload without a secret (Frontend safe)
import jwtDecode from 'jwt-decode';
const token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."; // Received from API
const decoded = jwtDecode(token);
console.log(decoded.userId); // 123
console.log(decoded.role); // 'admin'
// No secret key needed or used here
Where you run these libraries matters more than how you run them. jsonwebtoken depends on Node.js core crypto modules. More importantly, it requires your signing secret to function. If you bundle jsonwebtoken into a React or Vue app, you either face build errors (due to missing Node libs) or, worse, you might be tempted to hardcode your secret in the frontend code. Never do this. Anyone can view your source code and steal your secret to forge admin tokens.
jwt-decode has zero dependencies and works in any JavaScript environment, including browsers, Cloudflare Workers, and Deno. It is safe to ship to the client because it cannot verify or create tokensβit can only read them.
// β DANGEROUS: Never do this in frontend code
// import jwt from 'jsonwebtoken';
// const token = jwt.sign({ admin: true }, 'exposed_secret');
// Attackers can now see 'exposed_secret' in DevTools
// β
SAFE: Standard frontend pattern
import jwtDecode from 'jwt-decode';
function getUserRole() {
const token = localStorage.getItem('auth_token');
if (!token) return 'guest';
try {
const { role, exp } = jwtDecode(token);
// Check expiration manually if needed
if (exp * 1000 < Date.now()) return 'expired';
return role;
} catch (e) {
return 'invalid';
}
}
jsonwebtoken provides jwt.verify(), which mathematically proves the token was signed by your server and hasn't been altered. If the signature doesn't match the secret, it throws an error. This is your primary defense against tampering.
jwt-decode offers no such protection. It will happily decode a token even if the signature is invalid, the token is expired, or the token was completely made up by a hacker. When using jwt-decode on the client, you are trusting that your backend already verified the token before sending it. The client uses it only for convenience (like updating the UI), not for security decisions.
// jsonwebtoken: Strict verification (Backend)
try {
const payload = jwt.verify(token, secret);
// If we get here, the token is cryptographically valid
console.log('User is authenticated:', payload.userId);
} catch (err) {
// Token is invalid, expired, or tampered with
console.error('Access denied');
}
// jwt-decode: Blind decoding (Frontend)
try {
const payload = jwtDecode(token);
// This runs even if the token is fake!
// You MUST still send this token to your API for real verification
console.log('Local UI update:', payload.userId);
} catch (err) {
// Only catches malformed base64 strings, not bad signatures
console.error('Token format is broken');
}
jsonwebtoken is highly configurable. You can set algorithms (HS256, RS256), expiration times, issuer claims, and audience restrictions during both signing and verification. This flexibility is necessary for robust backend security policies.
jwt-decode has almost no configuration. Its only option is to specify whether the header should be included in the return value. This minimalism keeps the bundle size tiny and the API simple for frontend developers who just need the data.
// jsonwebtoken: Rich options for security policies
const token = jwt.sign(
{ sub: 'user_123' },
secret,
{
algorithm: 'RS256', // Use RSA instead of HMAC
expiresIn: '15m', // Short lifespan for security
audience: 'my-api', // Restrict who can use this token
issuer: 'my-auth-server' // Define who created it
}
);
// jwt-decode: Minimal options
// Default: returns only the payload
const payload = jwtDecode(token);
// Optional: include the header object as well
const fullData = jwtDecode(token, { header: true });
// Returns: { header: { alg: 'HS256'... }, payload: { ... } }
Both libraries handle time, but differently. jsonwebtoken automatically checks the exp (expiration) claim during verify() and rejects expired tokens. jwt-decode simply returns the exp timestamp as a number. It is up to you, the developer, to compare it against the current time.
This distinction reinforces their roles: the backend enforces expiration strictly; the frontend checks expiration gently to decide whether to show a "Session Expired" message or attempt a silent refresh.
// jsonwebtoken: Automatic expiration enforcement
try {
// Throws 'TokenExpiredError' automatically if expired
const data = jwt.verify(token, secret);
} catch (error) {
if (error.name === 'TokenExpiredError') {
console.log('Token has expired');
}
}
// jwt-decode: Manual expiration check
const { exp } = jwtDecode(token);
const isExpired = exp * 1000 < Date.now(); // Convert to milliseconds
if (isExpired) {
// Trigger refresh logic or redirect to login
refreshToken();
}
Despite their differences, both libraries operate on the same JWT standard (RFC 7519). They both parse the three-part structure of a JWT (Header.Payload.Signature) and handle the base64url encoding correctly. They are often used together in a single full-stack application: jsonwebtoken on the server to issue tokens, and jwt-decode on the client to read them.
// Both work with standard tokens generated by any compliant library
const standardToken = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U";
// Backend verifies it
// jwt.verify(standardToken, secret);
// Frontend reads it
// jwtDecode(standardToken);
// Resulting payload structure is the same regardless of library
// { sub: "1234567890", iat: 1516239022 }
jsonwebtoken throws on invalid signatures.try {
// Both throw if the string isn't a valid JWT format
// jwt.verify("not-a-token", secret);
// jwtDecode("not-a-token");
} catch (e) {
console.log("Invalid format");
}
| Feature | jsonwebtoken | jwt-decode |
|---|---|---|
| Primary Role | Sign and Verify tokens | Decode/Read token payload |
| Security Model | Cryptographic verification (HMAC/RSA) | No verification (Blind decoding) |
| Secret Key | Required (Must be kept secret) | Not Used (Safe for public code) |
| Environment | Node.js Backend only | Browser, Node, Edge (Anywhere) |
| Expiration | Automatic enforcement | Manual check required |
| Bundle Size | Larger (includes crypto libs) | Tiny (zero dependencies) |
| Use Case | Auth servers, API protection | UI state, silent refresh logic |
Think of jsonwebtoken as the bank vault. It holds the secrets, creates the valuable assets (tokens), and rigorously checks IDs before letting anyone in. It belongs strictly in the secure backend.
Think of jwt-decode as the ID card reader at the office turnstile. It reads the name and photo on the card to let you through the door (UI), but it doesn't know if the card is a forgery. It trusts that the bank (backend) already validated the card when it was issued.
Final Recommendation:
jsonwebtoken in your Node.js API to sign tokens upon login and verify them on every protected request.jwt-decode in your React/Vue/Angular app to read the user's name for the header, check if the token is about to expire, or redirect them if they are logged out.Choose jsonwebtoken if you are building a backend service (Node.js) that needs to issue new tokens or strictly verify incoming requests against a secret key. This package is essential for authentication servers, API gateways, or any environment where security secrets are managed. Do not use this in frontend code, as it requires exposing your private signing secret to the browser, which is a critical security vulnerability.
Choose jwt-decode for frontend applications (React, Vue, Angular, etc.) where you need to inspect the contents of a token received from an API. It is the correct tool for checking if a user is logged in, determining their permission level for UI elements, or deciding when to refresh a token based on expiration time. Use this when you only need to read data, not create or cryptographically verify the token's integrity.
| Build | Dependency |
|---|---|
An implementation of JSON Web Tokens.
This was developed against draft-ietf-oauth-json-web-token-08. It makes use of node-jws
$ npm install jsonwebtoken
(Asynchronous) If a callback is supplied, the callback is called with the err or the JWT.
(Synchronous) Returns the JsonWebToken as string
payload could be an object literal, buffer or string representing valid JSON.
Please note that
expor any other claim is only set if the payload is an object literal. Buffer or string payloads are not checked for JSON validity.
If
payloadis not a buffer or a string, it will be coerced into a string usingJSON.stringify.
secretOrPrivateKey is a string (utf-8 encoded), buffer, object, or KeyObject containing either the secret for HMAC algorithms or the PEM
encoded private key for RSA and ECDSA. In case of a private key with passphrase an object { key, passphrase } can be used (based on crypto documentation), in this case be sure you pass the algorithm option.
When signing with RSA algorithms the minimum modulus length is 2048 except when the allowInsecureKeySizes option is set to true. Private keys below this size will be rejected with an error.
options:
algorithm (default: HS256)expiresIn: expressed in seconds or a string describing a time span vercel/ms.
Eg:
60,"2 days","10h","7d". A numeric value is interpreted as a seconds count. If you use a string be sure you provide the time units (days, hours, etc), otherwise milliseconds unit is used by default ("120"is equal to"120ms").
notBefore: expressed in seconds or a string describing a time span vercel/ms.
Eg:
60,"2 days","10h","7d". A numeric value is interpreted as a seconds count. If you use a string be sure you provide the time units (days, hours, etc), otherwise milliseconds unit is used by default ("120"is equal to"120ms").
audienceissuerjwtidsubjectnoTimestampheaderkeyidmutatePayload: if true, the sign function will modify the payload object directly. This is useful if you need a raw reference to the payload after claims have been applied to it but before it has been encoded into a token.allowInsecureKeySizes: if true allows private keys with a modulus below 2048 to be used for RSAallowInvalidAsymmetricKeyTypes: if true, allows asymmetric keys which do not match the specified algorithm. This option is intended only for backwards compatability and should be avoided.There are no default values for
expiresIn,notBefore,audience,subject,issuer. These claims can also be provided in the payload directly withexp,nbf,aud,subandissrespectively, but you can't include in both places.
Remember that exp, nbf and iat are NumericDate, see related Token Expiration (exp claim)
The header can be customized via the options.header object.
Generated jwts will include an iat (issued at) claim by default unless noTimestamp is specified. If iat is inserted in the payload, it will be used instead of the real timestamp for calculating other things like exp given a timespan in options.expiresIn.
Synchronous Sign with default (HMAC SHA256)
var jwt = require('jsonwebtoken');
var token = jwt.sign({ foo: 'bar' }, 'shhhhh');
Synchronous Sign with RSA SHA256
// sign with RSA SHA256
var privateKey = fs.readFileSync('private.key');
var token = jwt.sign({ foo: 'bar' }, privateKey, { algorithm: 'RS256' });
Sign asynchronously
jwt.sign({ foo: 'bar' }, privateKey, { algorithm: 'RS256' }, function(err, token) {
console.log(token);
});
Backdate a jwt 30 seconds
var older_token = jwt.sign({ foo: 'bar', iat: Math.floor(Date.now() / 1000) - 30 }, 'shhhhh');
The standard for JWT defines an exp claim for expiration. The expiration is represented as a NumericDate:
A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the IEEE Std 1003.1, 2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in which each day is accounted for by exactly 86400 seconds, other than that non-integer values can be represented. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.
This means that the exp field should contain the number of seconds since the epoch.
Signing a token with 1 hour of expiration:
jwt.sign({
exp: Math.floor(Date.now() / 1000) + (60 * 60),
data: 'foobar'
}, 'secret');
Another way to generate a token like this with this library is:
jwt.sign({
data: 'foobar'
}, 'secret', { expiresIn: 60 * 60 });
//or even better:
jwt.sign({
data: 'foobar'
}, 'secret', { expiresIn: '1h' });
(Asynchronous) If a callback is supplied, function acts asynchronously. The callback is called with the decoded payload if the signature is valid and optional expiration, audience, or issuer are valid. If not, it will be called with the error.
(Synchronous) If a callback is not supplied, function acts synchronously. Returns the payload decoded if the signature is valid and optional expiration, audience, or issuer are valid. If not, it will throw the error.
Warning: When the token comes from an untrusted source (e.g. user input or external requests), the returned decoded payload should be treated like any other user input; please make sure to sanitize and only work with properties that are expected
token is the JsonWebToken string
secretOrPublicKey is a string (utf-8 encoded), buffer, or KeyObject containing either the secret for HMAC algorithms, or the PEM
encoded public key for RSA and ECDSA.
If jwt.verify is called asynchronous, secretOrPublicKey can be a function that should fetch the secret or public key. See below for a detailed example
As mentioned in this comment, there are other libraries that expect base64 encoded secrets (random bytes encoded using base64), if that is your case you can pass Buffer.from(secret, 'base64'), by doing this the secret will be decoded using base64 and the token verification will use the original random bytes.
options
algorithms: List of strings with the names of the allowed algorithms. For instance, ["HS256", "HS384"].
If not specified a defaults will be used based on the type of key provided
- secret - ['HS256', 'HS384', 'HS512']
- rsa - ['RS256', 'RS384', 'RS512']
- ec - ['ES256', 'ES384', 'ES512']
- default - ['RS256', 'RS384', 'RS512']
audience: if you want to check audience (aud), provide a value here. The audience can be checked against a string, a regular expression or a list of strings and/or regular expressions.
Eg:
"urn:foo",/urn:f[o]{2}/,[/urn:f[o]{2}/, "urn:bar"]
complete: return an object with the decoded { payload, header, signature } instead of only the usual content of the payload.issuer (optional): string or array of strings of valid values for the iss field.jwtid (optional): if you want to check JWT ID (jti), provide a string value here.ignoreExpiration: if true do not validate the expiration of the token.ignoreNotBefore...subject: if you want to check subject (sub), provide a value hereclockTolerance: number of seconds to tolerate when checking the nbf and exp claims, to deal with small clock differences among different serversmaxAge: the maximum allowed age for tokens to still be valid. It is expressed in seconds or a string describing a time span vercel/ms.
Eg:
1000,"2 days","10h","7d". A numeric value is interpreted as a seconds count. If you use a string be sure you provide the time units (days, hours, etc), otherwise milliseconds unit is used by default ("120"is equal to"120ms").
clockTimestamp: the time in seconds that should be used as the current time for all necessary comparisons.nonce: if you want to check nonce claim, provide a string value here. It is used on Open ID for the ID Tokens. (Open ID implementation notes)allowInvalidAsymmetricKeyTypes: if true, allows asymmetric keys which do not match the specified algorithm. This option is intended only for backwards compatability and should be avoided.// verify a token symmetric - synchronous
var decoded = jwt.verify(token, 'shhhhh');
console.log(decoded.foo) // bar
// verify a token symmetric
jwt.verify(token, 'shhhhh', function(err, decoded) {
console.log(decoded.foo) // bar
});
// invalid token - synchronous
try {
var decoded = jwt.verify(token, 'wrong-secret');
} catch(err) {
// err
}
// invalid token
jwt.verify(token, 'wrong-secret', function(err, decoded) {
// err
// decoded undefined
});
// verify a token asymmetric
var cert = fs.readFileSync('public.pem'); // get public key
jwt.verify(token, cert, function(err, decoded) {
console.log(decoded.foo) // bar
});
// verify audience
var cert = fs.readFileSync('public.pem'); // get public key
jwt.verify(token, cert, { audience: 'urn:foo' }, function(err, decoded) {
// if audience mismatch, err == invalid audience
});
// verify issuer
var cert = fs.readFileSync('public.pem'); // get public key
jwt.verify(token, cert, { audience: 'urn:foo', issuer: 'urn:issuer' }, function(err, decoded) {
// if issuer mismatch, err == invalid issuer
});
// verify jwt id
var cert = fs.readFileSync('public.pem'); // get public key
jwt.verify(token, cert, { audience: 'urn:foo', issuer: 'urn:issuer', jwtid: 'jwtid' }, function(err, decoded) {
// if jwt id mismatch, err == invalid jwt id
});
// verify subject
var cert = fs.readFileSync('public.pem'); // get public key
jwt.verify(token, cert, { audience: 'urn:foo', issuer: 'urn:issuer', jwtid: 'jwtid', subject: 'subject' }, function(err, decoded) {
// if subject mismatch, err == invalid subject
});
// alg mismatch
var cert = fs.readFileSync('public.pem'); // get public key
jwt.verify(token, cert, { algorithms: ['RS256'] }, function (err, payload) {
// if token alg != RS256, err == invalid signature
});
// Verify using getKey callback
// Example uses https://github.com/auth0/node-jwks-rsa as a way to fetch the keys.
var jwksClient = require('jwks-rsa');
var client = jwksClient({
jwksUri: 'https://sandrino.auth0.com/.well-known/jwks.json'
});
function getKey(header, callback){
client.getSigningKey(header.kid, function(err, key) {
var signingKey = key.publicKey || key.rsaPublicKey;
callback(null, signingKey);
});
}
jwt.verify(token, getKey, options, function(err, decoded) {
console.log(decoded.foo) // bar
});
(Synchronous) Returns the decoded payload without verifying if the signature is valid.
Warning: This will not verify whether the signature is valid. You should not use this for untrusted messages. You most likely want to use
jwt.verifyinstead.
Warning: When the token comes from an untrusted source (e.g. user input or external request), the returned decoded payload should be treated like any other user input; please make sure to sanitize and only work with properties that are expected
token is the JsonWebToken string
options:
json: force JSON.parse on the payload even if the header doesn't contain "typ":"JWT".complete: return an object with the decoded payload and header.Example
// get the decoded payload ignoring signature, no secretOrPrivateKey needed
var decoded = jwt.decode(token);
// get the decoded payload and header
var decoded = jwt.decode(token, {complete: true});
console.log(decoded.header);
console.log(decoded.payload)
Possible thrown errors during verification. Error is the first argument of the verification callback.
Thrown error if the token is expired.
Error object:
jwt.verify(token, 'shhhhh', function(err, decoded) {
if (err) {
/*
err = {
name: 'TokenExpiredError',
message: 'jwt expired',
expiredAt: 1408621000
}
*/
}
});
Error object:
.)jwt.verify(token, 'shhhhh', function(err, decoded) {
if (err) {
/*
err = {
name: 'JsonWebTokenError',
message: 'jwt malformed'
}
*/
}
});
Thrown if current time is before the nbf claim.
Error object:
jwt.verify(token, 'shhhhh', function(err, decoded) {
if (err) {
/*
err = {
name: 'NotBeforeError',
message: 'jwt not active',
date: 2018-10-04T16:10:44.000Z
}
*/
}
});
Array of supported algorithms. The following algorithms are currently supported.
| alg Parameter Value | Digital Signature or MAC Algorithm |
|---|---|
| HS256 | HMAC using SHA-256 hash algorithm |
| HS384 | HMAC using SHA-384 hash algorithm |
| HS512 | HMAC using SHA-512 hash algorithm |
| RS256 | RSASSA-PKCS1-v1_5 using SHA-256 hash algorithm |
| RS384 | RSASSA-PKCS1-v1_5 using SHA-384 hash algorithm |
| RS512 | RSASSA-PKCS1-v1_5 using SHA-512 hash algorithm |
| PS256 | RSASSA-PSS using SHA-256 hash algorithm (only node ^6.12.0 OR >=8.0.0) |
| PS384 | RSASSA-PSS using SHA-384 hash algorithm (only node ^6.12.0 OR >=8.0.0) |
| PS512 | RSASSA-PSS using SHA-512 hash algorithm (only node ^6.12.0 OR >=8.0.0) |
| ES256 | ECDSA using P-256 curve and SHA-256 hash algorithm |
| ES384 | ECDSA using P-384 curve and SHA-384 hash algorithm |
| ES512 | ECDSA using P-521 curve and SHA-512 hash algorithm |
| none | No digital signature or MAC value included |
First of all, we recommend you to think carefully if auto-refreshing a JWT will not introduce any vulnerability in your system.
We are not comfortable including this as part of the library, however, you can take a look at this example to show how this could be accomplished. Apart from that example there are an issue and a pull request to get more knowledge about this topic.
If you have found a bug or if you have a feature request, please report them at this repository issues section. Please do not report security vulnerabilities on the public GitHub issue tracker. The Responsible Disclosure Program details the procedure for disclosing security issues.
This project is licensed under the MIT license. See the LICENSE file for more info.