HS256 in base64url
- Input
- 32 bytes
- Expected output
- 43 caracteres, 256 bits
RFC 7518 minimum for HS256.
generate jwt secret hs256
Pick JWT HS256, HS384 or HS512 in the generator: the size already sits at the RFC 7518 minimum and you only choose the encoding. The result brings the value ready for a JWT_SECRET variable.
RFC 7518 minimum for HS256.
Two characters per byte.
48 is a multiple of 3, so there is no padding.
In standard base64 it would be 88, with two =.
The same 32 bytes in standard base64.
Use at least 32 random bytes (256 bits): RFC 7518, section 3.2, says the HMAC key must be the size of the hash output or larger, that is 256 bits for HS256, 384 for HS384 and 512 for HS512. A short phrase or dictionary word as the secret can be cracked by offline brute force from a single token.
It may work, but it is risky: passwords carry far less entropy than 256 bits and can be found by brute force from one token. Generate random bytes with the generator.
It depends on the library. Some take text and use its UTF-8 bytes; others want a buffer. What matters is that the signer and the verifier use exactly the same handling.
Only if the secret is larger too. With 32 bytes of entropy, HS512 does not exceed 256 bits of security. The secret is what protects you, not the algorithm name.
Random bytes in hexadecimal: 2 characters per byte. 32 bytes give 64 characters and 256 bits.
openssl rand -hex 32python3 -c "import secrets; print(secrets.token_hex(32))"Pick the variables and copy the block. Each generation draws new values; values with $, # or spaces come out quoted.
Turn on at least one variable.
For production, prefer generating locally with the terminal command. Any secret typed or copied from a web page should be treated as exposed if you do not trust the device or the browser extensions. Nothing here is sent or stored.