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 | — |
| Characters outside b64token | — |
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. 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 tool reports whether your token matches it. Real deployments do use opaque tokens with other characters — RFC 6749 Appendix A.12 allows the wider `access-token = 1*VSCHAR` (%x20-7E) in the token response — so a non-conformant token is still emitted, just flagged. This tool never sends or stores the token — treat a bearer token as a live credential and send it only over TLS. To inspect a JWT's claims, use the JWT Decoder.