Build, inspect and copy HTTP authentication headers without mixing schemes together.
Pick one method, fill only its fields, and take the finished header, the working behind it,
or ready-to-run code. Basic, Bearer, API key, RFC 7616
Digest, AWS Signature V4 and your own HMAC — every hash computed in this tab.
Joins the username and password with a colon and Base64-encodes the result. Base64 is encoding, not encryption — anyone who sees the header reads the password, so this needs HTTPS. The colon is the separator, which is why a username can never contain one.
Sends a token exactly as issued. If you paste a JWT, its header and payload are decoded in the working below so you can check the claims and expiry before sending it. The signature is never verified here — that needs the issuer's key.
A plain shared secret in a header of your choosing. There is no standard for this, which is why the name is a field rather than a constant — it is whatever the API you are calling expects.
The password itself never travels. The server sends a nonce and you return a hash built
from the password, that nonce and the request line. Every field except the password is
copied from the WWW-Authenticate header of the server's 401 — a stale
nonce is rejected.
The secret key never travels: it derives a signing key scoped to one date, region and service, which then signs a canonical form of the whole request. Works unchanged for anything S3-compatible — Cloudflare R2, MinIO, Backblaze B2, Wasabi, DigitalOcean Spaces.
Many APIs define their own signature: hash an agreed string with a shared secret. Use
{method}, {path}, {host}, {timestamp},
{nonce}, {keyId} and {bodyHash} as placeholders, and
press Enter for a real newline — getting the separators wrong is the usual cause of a 401.
Paste the whole line as copied from devtools, curl -v or a log — or just
the value. The scheme is detected automatically: Basic, Bearer, JWT, Digest, AWS SigV4 and
plain API-key headers are all understood. It decodes as you type.
| Scheme | Secret sent? | Replay-safe? | Needs TLS | Typical use |
|---|---|---|---|---|
| Basic | Yes — reversible Base64 | No | Mandatory | Internal tools, quick scripts |
| Bearer | Yes — the token itself | No | Mandatory | OAuth 2.0, most modern APIs |
| API Key | Yes — the key itself | No | Mandatory | Server-to-server, rate limiting |
| Digest | No — only a hash | Yes, via nonce | Recommended | Legacy devices, routers |
| AWS SigV4 | No — derived key | Yes, signed timestamp | Recommended | AWS APIs, S3-compatible storage |
| Custom HMAC | No — only a signature | Yes, if timestamped | Recommended | Webhooks, payment APIs |
Nothing here reaches our server. This page has no backend: the Base64, the MD5 and SHA-256 hashes and the HMAC chains all run in your tab through the Web Crypto API. You can verify that in one step — open your browser's Network tab and generate a header; there is no request to see. The usual caveat still applies to any browser tab: an extension with page-read access can read what you type, so for a live production root key, sign on your own machine.
The Authorization header has one grammar — a scheme token, a space, then
credentials in whatever shape the scheme defines — and wildly different security properties
behind it. The distinction that matters in practice is the one the table above is built around:
what does an attacker get by reading a single request?
For the top three, everything. Basic carries the password in a form that decodes in one step, Bearer carries a token that is replayable until it expires, and an API key is usually valid until somebody rotates it by hand. For the bottom three, nothing reusable. Digest, SigV4 and a well-designed HMAC scheme all send proof that you hold a secret rather than the secret itself, which is why SigV4 goes to the trouble of a canonical request: signing the method, host, path, query, headers and a hash of the body means a captured signature cannot be moved to a different request. An in-house HMAC scheme is only as good as its canonical string — sign a timestamp and you get replay protection, sign the body hash and you get integrity, sign only the path and you have built Basic auth with extra steps.
These tools all work on the same connection and address data — pick whichever question you actually have.
Nothing you type is transmitted. There is no API endpoint behind this route and no fetch in its JavaScript — the Base64, the MD5 and SHA-256 hashes and the HMAC chains all run in your tab through the Web Crypto API. Open your browser's Network tab while you generate a header and you will see no request at all, which is a stronger assurance than anything this sentence can claim. The honest caveat is the one that applies to every web page: a browser extension with permission to read the page can read what you type into it. For a live production root key, sign on your own machine.
Because it is reversible with no key. Basic YWxhZGRpbjpvcGVuIHNlc2FtZQ== decodes to aladdin:open sesame in one step, which the decode tab here will do for you. Base64 exists to make arbitrary bytes safe to put in a header, not to hide them. Basic authentication is therefore only ever acceptable over HTTPS, where TLS — not the encoding — is what keeps the password private.
They answer different questions. Bearer is the transport — RFC 6750 says put the token after the word Bearer and whoever holds it is authorised. JWT is one possible format for that token: a signed, base64url-encoded JSON structure. So every JWT sent this way is a bearer token, but plenty of bearer tokens are opaque random strings with no readable contents. If your token has two dots in it, this page decodes its claims automatically — but it never verifies the signature, which needs the issuer's key.
AWS returns that same error for every possible mistake, but it also echoes the canonical request it expected. Compare it line by line with the one under "How this value was computed" — the difference is almost always one of four things: a header you signed but did not send (or sent but did not sign), a query string sorted differently, a payload hash computed over a body that changed, or a clock more than a few minutes out. The x-amz-date you sign and the one you send must be identical.
Because the devices that speak Digest were built before the alternative existed. RFC 7616 added SHA-256 in 2015, and almost nothing implements it — routers, NAS boxes, IP cameras and SIP gateways still send algorithm=MD5 in their challenge, and a client has to answer in the algorithm it was challenged with. This tool computes MD5 for that reason, not as an endorsement. Digest also authenticates only the method and the URI, never the response, so it is only meaningful inside TLS.
A header, whenever the API allows it. A key in the query string is written into every access log, proxy log and browser history entry along the path, is carried in the Referer header of any link the page then follows, and shows up in analytics. None of those are places you can retrospectively scrub. The query-string option is here because some older APIs accept nothing else, and the tool says so when you pick it.
At minimum the method, the path with its query string, and a timestamp — the timestamp is what stops a captured signature being replayed tomorrow, provided the server also rejects stale ones. Add a SHA-256 hash of the body for any request that has one, or an attacker can swap the body while keeping your signature valid. Add a nonce if you need protection against replay inside the timestamp window. Join the parts with a separator that cannot appear in the values, and make sure both sides agree on it exactly: a client joining with a literal backslash-n while the server joins with a real newline is the classic all-day bug.
Yes. Cloudflare R2, MinIO, Backblaze B2, Wasabi and DigitalOcean Spaces all implement Signature Version 4 unchanged — put their endpoint in the URL field, keep the service as s3, and use whichever region string that provider expects (R2 uses auto). Keep x-amz-content-sha256 signed: it is required by the S3 API regardless of who is implementing it.
Basic, Bearer, Digest, HOBA, Mutual, Negotiate, SCRAM-SHA-1, SCRAM-SHA-256 and vapid are in the IANA HTTP Authentication Scheme Registry. Everything else — AWS SigV4, every vendor HMAC scheme, and the whole X-API-Key convention — is a private arrangement between one API and its clients. That is not a fault, but it does mean there is no spec to appeal to when two implementations disagree, which is why this page shows the exact bytes it signed.
