HS256 signs a JWT with one shared secret using HMAC-SHA-256, while RS256 signs it with a private RSA key whose public counterpart anyone can verify against. The choice between them depends on who needs to check the token: a symmetric secret works inside one trust boundary, an asymmetric key pair works when many independent parties must verify without sharing signing material. A browser-only HS256 tool such as the JWT Generator covers most local development, integration testing, and single-domain token workflows without provisioning certificates or uploading payloads, because everything runs through Web Crypto in the current tab. RS256 needs a different toolchain because the signer needs the private key and the verifier needs the matching public key. The rest of this article walks through what the JWT Generator actually emits, how to prepare its strict JSON claims and a sufficiently long HMAC secret, and how to verify the result against a maintained JOSE library before promoting the token to a real environment.
HS256 vs RS256: The Choice Behind a Browser Token Tool
Two algorithms dominate the JSON Web Signature space defined by RFC 7515. HS256 is a Message Authentication Code built on HMAC with a SHA-256 digest. The same byte string acts as both the signing key and the verification key, so every party that validates a token must possess it. RS256, defined in RFC 7518, is an asymmetric signature built on RSASSA-PKCS1-v1_5 with SHA-256. The signer holds a private RSA key, and verifiers only need the public counterpart, often distributed through a JWKS endpoint, a static certificate, or a PEM file.
The practical question is not which algorithm is better in the abstract; it is who has to verify the token. A back-end service that issues and consumes its own tokens in the same codebase benefits from HS256 because there is exactly one secret to manage and rotation is a single swap. A token that is minted by one organization and consumed by dozens of independent clients — identity providers, federated APIs, or open platforms — benefits from RS256 because clients only need the public key to check the signature and never hold signing material. Browser-only tooling typically targets HS256 because bringing an RSA private key into a public web page would defeat its purpose.
If the search for "generate JWT token online RS256" comes from a need to verify against a public key, a browser tool is probably not the right answer; a local CLI or a server-side process that owns the private key is required. If the search comes from a development task where HS256 will work — local API tests, GitHub App authentication, a service-to-service token inside one boundary — a browser tool is the fastest path.
The Output Shape of the JWT Generator
The JWT Generator emits exactly one thing: a compact JSON Web Signature whose protected header is fixed to alg: HS256, typ: JWT. Fixing the algorithm is a deliberate decision: it prevents the token from being silently switched to none, to a mismatched asymmetric algorithm, or to any other value that the destination system does not intend to accept. The signed output is three base64url segments separated by periods — header.payload.signature — encoded with the URL-safe alphabet and no equals padding, as specified in RFC 7515.
The generator takes two inputs and nothing else. The first is a strict JSON claims object, which is rejected if it contains arrays at the top level, null as the root, comments, trailing commas, undefined, NaN, Infinity, or any JavaScript expression. The second is a UTF-8 secret that must be at least 32 bytes long, matching the HS256 key-size floor associated with the 256-bit hash output. A random button is offered for testing; it generates 32 cryptographically random bytes and displays them as 64 hexadecimal characters. Treat those bytes as visible development material, not automatically provisioned production secrets.
| Property | HS256 (JWT Generator) | RS256 (not supported here) |
|---|---|---|
| Algorithm class | MAC, symmetric | Signature, asymmetric |
| Key material | Shared secret, at least 32 UTF-8 bytes | RSA private key (signer) plus RSA public key (verifier) |
| Verifier requirements | Same secret as the signer | Public key only, distributed via JWKS, certificate, or PEM |
| Typical use case | Single trust domain, internal APIs, GitHub Apps, local testing | Federated identity, third-party verification, open platforms |
| Browser tooling | Native via Web Crypto, no upload | Unsafe in a public page — the private key would leak |
| Reference | RFC 7518, MAC with SHA-256 | RFC 7518, RSASSA-PKCS1-v1_5 with SHA-256 |
If the destination specifically requires RS256, the JWT Generator will not produce one. That boundary is intentional: generating an RS256 token in a public web page would require uploading or typing a private key, which destroys the value of running locally. A server-side script, an OpenSSL-driven CLI, or a maintained library is the right tool there.
Prepare the Claims Object and the HMAC Secret
Before clicking anything, decide exactly which claims the destination service expects. The generator does not add iat, exp, nbf, iss, sub, aud, jti, or any other standard claim automatically. You are responsible for authoritative values: iss and aud must match what the verifier checks, and any exp value must be expressed in seconds since the Unix epoch, not JavaScript milliseconds. A numeric value such as 1717500000 is seconds; the equivalent in milliseconds would be 1717500000000. Confusing the two is one of the most common reasons a token fails verification despite looking valid.
Keep the JSON object strictly conformant. A claims shape that mirrors what many APIs expect:
- iss — issuer string, for example a service name or tenant identifier
- sub — subject identifier, usually the user or system being authenticated
- aud — audience string, exactly what the receiving service names itself
- iat — issued-at time, in epoch seconds
- exp — expiration time, in epoch seconds
- jti — unique token identifier, when the service tracks replays
For the secret, paste a non-production string of at least 32 UTF-8 bytes, or click the random button for a 64-character hex value. Remember that character count and byte count differ for non-ASCII text: a 32-character passphrase made of single-byte ASCII characters is exactly 32 bytes, but 32 emoji glyphs typically encode to roughly 128 bytes. The check is byte-based, not character-based.
Generate, Inspect, and Copy the HS256 Token
With the claims and secret ready, the actual generation is three steps. The tool is designed so that each step produces an inspectable artifact — the token output should never be treated as opaque.
- Paste the strict JSON claims object into the claims field and enter a non-production UTF-8 secret of at least 32 bytes, or generate one through the random button for testing material.
- Generate the HS256 token and review the three compact segments: the fixed header eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9, the base64url-encoded payload, and the base64url-encoded signature. The header will always decode to {"alg":"HS256","typ":"JWT"}. Confirm that the claims output reflects exactly what was typed and that nothing confidential — passwords, private keys, personal records — has slipped in.
- Copy the token and verify it with the target JOSE library using explicit algorithm, issuer, audience, lifetime, and key policy. Never promote a token to staging or production based on the generator alone.
Two pieces of metadata deserve attention when the segments are inspected. First, segment length is informative: a compact HS256 token is roughly 1.5 times the length of the raw payload plus a fixed header and a 43-character signature. A result that is unexpectedly short usually means the claims object was truncated; a result that is unexpectedly long usually means JSON that the parser accepted but the service did not expect has been embedded. Second, the generator's own output is not self-verified. Treat the page as a signer, not a validator. To confirm that the token round-trips correctly, paste it into a decoder such as the JWT Decoder and cross-check the header and payload segments against what was typed.
Verify the Generated Token With a Production JOSE Library
A browser tool that emits a syntactically correct token still cannot guarantee that the destination will accept it. Verification belongs in the production codebase, not on the generation page. Take the copied token and pass it to the target JOSE library — jsonwebtoken, jose, PyJWT, java-jwt, or the equivalent in the target stack — with all four policy checks explicit.
First, pin the algorithm. The library should be told to accept only HS256 and to reject any other alg value, including none. Algorithm confusion attacks exploit verifiers that accept whatever the header declares. Second, verify iss and aud as exact strings, not as substrings or regular expressions, against the values the issuer and the destination were configured with. Third, check exp, nbf, and iat with a small clock-skew tolerance that is documented in the security model; rejecting tokens that expire one millisecond in the future is rarely the desired behavior. Fourth, supply the secret or key through the same secret-management path the rest of the service uses, not through an environment variable that is overridden in tests.
RFC 7515 is the authoritative reference for the compact serialization format, and RFC 7518 is the authoritative reference for the cryptographic algorithms themselves. When the generator's output disagrees with the library's reading, the dispute is almost always about a claim value, an algorithm mismatch, or a key rotation the verifier has not yet picked up. Treat the generator as a faithful signer; treat the library as the source of truth for acceptance.
When You Actually Need RS256 and How to Switch
If the destination specifically requires RS256 — because it fetches a JWKS, validates against a public certificate, or rejects HS256 outright — a browser-based HS256 generator is the wrong tool and should not be adapted. RS256 verification expects the verifier to hold the public half of an RSA key pair and the signer to hold the private half. Importing a private key into a public web page destroys the security property that justifies the algorithm. The right paths are:
- A local CLI driven by openssl or by a maintained JWT library that reads a PEM private key from disk and signs locally
- A server-side script invoked from CI that uses the project's own signer, not a public web form
- A maintained JOSE library inside the issuing service, where the private key never leaves the trust boundary
For workflows that are happy with HS256, the JWT Generator remains a complete browser-based signer. For GitHub App authentication specifically, where HS256 is the documented requirement, the dedicated HS256 GitHub App guide walks through the exact claim shape and expiration policy that GitHub's API expects.
Two final cautions apply to both algorithms. Copying or displaying a token can expose bearer credentials through clipboard history, screenshots, browser extensions, logs, support tickets, or chat — only non-production claims and secrets should appear on any generator page. If a real secret or active token is pasted into any environment outside its intended boundary, rotate or revoke it rather than assuming the local implementation made disclosure harmless. The browser is a useful shortcut for development, not a safe home for production credentials.
For a deeper look, see Set Up a Shortcut for Arrow Functions in VS Code.