Why does Postman reject my self-generated JWT?

Most rejections come from the server, not from Postman. Common causes: the verifier restricts its algorithm allowlist and rejects HS256 because the server expects RS256, the claim names differ (aud sent as a string but expected as an array), the exp NumericDate is in milliseconds instead of seconds, or the secret on the server does not match the secret in the generator. Check the server logs for the specific failure before adjusting the token.

Should I generate the token in Postman's Pre-request Script or with an external tool?

Use a Pre-request Script when you need repeatable, automated refresh inside CI or scheduled collection runs. Use a browser-based generator when you want the secret to stay in your current tab, when you want to inspect the three segments visually, or when you are producing one-off tokens for ad-hoc testing. Both approaches produce the same shape of HS256 token.

Can I paste a real production secret into the generator?

No. The generator processes claims and key material inside the current browser tab, but copying or displaying a token can expose bearer credentials through clipboard history, screenshots, browser extensions, logs, support tickets, or chat. Use only non-production claims and secrets. If a real secret or active token has been pasted into any environment outside its intended boundary, rotate or revoke it.

Why is the JWT header locked to HS256?

A fixed algorithm makes the generator's behavior explicit and avoids producing algorithm-confusion or unsecured tokens. Other algorithms require different key types and production libraries. Locking the header prevents user input from silently selecting none, a mismatched asymmetric algorithm, or another value that the destination does not intend to accept.

Generate a JWT Token in Postman with HS256 Locally

What "Generate JWT Token in Postman" Actually Means

A JSON Web Token used inside Postman is a compact, three-segment string of base64url-encoded data. The first segment is a header that names the signing algorithm, the second is a JSON payload of claims, and the third is an HS256 HMAC-SHA-256 signature that ties those two segments to a shared secret. Postman does not validate the token itself; it forwards whatever string you place in its Authorization tab as the request's bearer credential. So "generate a JWT token in Postman" really means "produce an HS256 token that Postman will happily send on your behalf," and that production step can live either inside Postman's Pre-request Script or in a separate, browser-based tool.

The two paths look different on the surface. A Pre-request Script encodes the segments in JavaScript, signs with a key from a Postman variable, and stores the result in a collection variable. The browser-based JWT Generator accepts a strict JSON claims object and a UTF-8 secret, performs the same encoding and signing with Web Crypto, and hands you the finished compact string to paste. The output is the same shape of token; only the place where the cryptography runs and the visibility of the secret during generation change.

Why a Browser-Based Generator Fits the Postman Workflow

Postman collections are often shared among teammates, version-controlled, and re-run in CI. Building tokens inside Pre-request Scripts couples the secret to the collection file and the variable store, which is convenient for repeatability but easy to leak when the collection is exported. Generating the token in a browser tool keeps the secret inside the current tab; claims and key material are processed with Web Crypto and never leave the page. You can paste the finished token into a Postman environment variable named something like jwt_test and reference it as {{jwt_test}} in the Authorization tab without ever storing the secret in the collection itself.

A second benefit is auditability. When the algorithm is fixed to HS256 and the header is locked to {"alg":"HS256","typ":"JWT"}, the token you produce cannot silently downgrade to none, switch to an asymmetric algorithm, or invent an unexpected value the destination does not intend to accept. Postman will forward the string in both scenarios, and a server that allows algorithm confusion is a well-known failure pattern. Using a tool whose output is provably HS256 removes that variable from the request side of the equation.

Approach	Where cryptography runs	Secret visibility during generation	Best fit
Postman Pre-request Script	Inside the request sandbox	Stored in Postman variables or environment	Repeatable runs, CI, automated refresh
Browser-based JWT Generator	Local browser tab via Web Crypto	Stays in the current tab only	Ad-hoc testing, one-off tokens, claim inspection
Server-side helper endpoint	Backend service	Server-controlled secret store	Production token issuance, identity-provider flows

The middle row, the JWT Generator, sits between fully scripted and fully server-driven flows. It is most useful when you need a real HS256 string for Postman but do not want to write or maintain a Pre-request Script.

How to Generate a JWT Token with the Generator

Paste a strict JSON claims object. The input must be a JSON object, not an array, comment, or JavaScript expression. Arrays, null, trailing commas, and undefined or NaN values are rejected. A minimal claims object for Postman testing looks like {"iss":"test-issuer","sub":"test-user","aud":"test-api","iat":1700000000,"exp":1700003600}. The iat and exp values are NumericDates, which are seconds from the Unix epoch, not JavaScript milliseconds.
Enter a secret of at least 32 UTF-8 bytes, or click the random button. The key-size floor associated with HS256's 256-bit hash output is enforced. Character count and byte count differ for non-ASCII text, so multibyte secrets need more characters than you might expect. The random button generates 32 cryptographically random bytes and displays them as 64 hexadecimal characters, which are then used as the UTF-8 HMAC secret.
Generate the HS256 token. The protected header is locked to {"alg":"HS256","typ":"JWT"}; the header and claims are UTF-8 encoded, converted to base64url with the URL-safe alphabet, and emitted without equals padding. The signing input is base64url(header) + "." + base64url(payload), signed with browser WebCrypto HMAC-SHA-256 using the raw key. The signature is base64url-encoded as the third segment.
Review the three compact segments. Two periods separate the header, payload, and signature. Confirm that the first segment decodes to {"alg":"HS256","typ":"JWT"}, that the second segment decodes to the claims you pasted, and that no confidential data has slipped into either.
Copy the token and verify it. Validate the finished string against your target JOSE library before trusting it in Postman. Use explicit algorithm allowlists, issuer and audience checks, lifetime validation, and the correct key policy. The token you produce is one component of a complete trust decision; the production verifier does the rest.

Adding the Token to a Postman Request

Once the JWT is in your clipboard, open the Postman request that needs authentication. In the Authorization tab, set Type to Bearer Token and paste the full three-segment string into the Token field on the right. Postman sends Authorization: Bearer <token> on every request issued from that tab; there is no client-side validation, so any well-formed string is forwarded as-is.

For collections that re-run frequently, store the token in an environment variable. Open the environment's variable list, add jwt_test with the token string as the value, and reference it inside the Bearer Token field as {{jwt_test}}. To refresh tokens, regenerate with the JWT Generator, update the variable, and re-send the request. This pattern keeps the secret out of the collection JSON that gets exported and shared, while still letting every request reuse the latest token.

Two practical Postman settings matter at this stage. First, make sure the workspace environment is the active one: Postman evaluates the bearer string at request time, not at save time, so swapping environments can silently change the credential. Second, watch for whitespace; a newline accidentally added when pasting from a clipboard manager turns the token into an invalid string and produces an authentication error from the server.

Verifying the Token Before Sending Requests

A self-made token can be syntactically perfect and still be unsafe. The HS256 signature only proves that whoever held the secret signed the header and payload together; it does not prove that the claims are true, current, or intended for the receiving service. Before you point a Postman request at a real API, run the token through the production verifier with the same algorithm, issuer, audience, lifetime, and key policy that the service will apply. The verification step is covered in detail in Generate a JWT for Testing: HS256 Tokens in Your Browser, which walks through the same HS256 outputs from a different angle.

If you need to inspect a token's claims locally, perhaps to confirm what Postman is actually sending, paste the string into Decode JWT Tokens Without Code in Your Browser. Decoding is unverified: it base64url-decodes the header and payload but does not check the signature. Treat the result as "what the token claims," not "what the token proves."

The compact serialization used by the JWT Generator follows RFC 7515, and the HS256 algorithm itself is specified in RFC 7518. When the verifier reports a mismatch, the usual suspects are: header algorithm was not restricted to HS256, the secret on the server does not match what you typed in the tool, the claim names differ from what the server validates (an aud array vs. string), or the exp NumericDate is in milliseconds instead of seconds.

Common Pitfalls When Using Self-Made Tokens in Postman

The most common failure is treating the token as if it were encrypted. HS256 is a message authentication code, not encryption; anyone who receives the token can base64url-decode the header and payload without the secret. Never put passwords, private keys, personal records, or confidential application data into the claims merely because the token is signed.

The second pitfall is reusing a development secret across environments. The random secret button produces a strong 32-byte value, but it is displayed in the browser and visible during generation. That value belongs to the development tab, not to a production secret store. If a real secret or active token has been pasted into any environment outside its intended boundary, rotate or revoke it instead of assuming the local tool kept it safe.

The third pitfall is letting the token outlive its claims. The generator does not add iat, exp, nbf, iss, sub, aud, jti, or any other claim automatically. You decide the issuer name, the audience identifier, the lifetime window, the clock-skew tolerance, the key rotation policy, and the revocation strategy. A long-lived token in a Postman environment variable is convenient for a one-hour debugging session and dangerous the next morning.

Finally, remember that Postman is not the trust boundary; the server is. If the server accepts your self-made token, the server has decided that HS256 with the secret you used is sufficient. If the server rejects it, fix the verifier's algorithm allowlist, claim names, key policy, or lifetime check before debugging the tool.