Bearer Header Builder
Turn an access token into an Authorization: Bearer header (RFC 6750), with a curl snippet and an RFC 6750 b64token conformance check.
This tool handles input and primary processing in your browser and is designed not to send the input to QuickKit’s server.
Avoid live production secrets; use dummy or masked data where possible. Data handling details
Header
| Header line | — |
|---|---|
| Header value | — |
| curl | — |
| RFC 6750 b64token | — |
| Non-conforming characters or padding | — |
How it works
OAuth 2.0 bearer tokens (RFC 6750) travel in `Authorization: Bearer <token>`. Paste a bare token, `Bearer <token>`, or a full header line — an optional `Authorization:` field name and the `Bearer` scheme are recognized and removed. After `Authorization:` the value is read as RFC 9110 credentials, which always start with a case-insensitive auth scheme: only `Authorization: Bearer <token>` yields a token, while `Authorization: Basic …`, `Authorization: Bearer` with no token, and `Authorization: <token>` without `Bearer` (read as a scheme named after the token) are errors and generate nothing. Without the `Authorization:` label, input that does not start with `Bearer` and a space is the token itself, so a bare `Bearer` or `Bearerabc` is used as a token.
Per RFC 6750 §2.1 the scheme and the token are separated by `1*SP` — one or more ASCII spaces, not a tab — so `Bearer<tab>token` is rejected. Everything after that separator is the token and is used verbatim: it is never trimmed, so leading, trailing, or internal whitespace and control characters are rejected rather than silently repaired, because they would break the header or allow header injection.
RFC 6750 §2.1 defines the header transport grammar as `b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="` (the same characters as `token68` in RFC 9110), and the header, header line, and curl snippet are generated only for a token that matches it. RFC 6749 Appendix A.12 allows the wider `access-token = 1*VSCHAR` (%x20-7E) in a token response, but that is not the Authorization header grammar: for a token outside `b64token` the tool generates nothing to copy, lists each offending character with its code point and the rule it breaks (for example `=` anywhere but the trailing padding), and leaves the token unchanged — it is never encoded, truncated, or repaired.
This tool does not send the token to the server or put it in the URL. Copy puts the header, token included, on your clipboard, where it can stay (and in any clipboard history) until replaced — clear it when you are done. Treat a bearer token as a live credential and send it only over TLS. To inspect a JWT's claims, use the JWT Decoder.