Authorization Header生成器 - JWT转Bearer请求头/cURL/Fetch（免费）

拿到 Token 之后，还差一个”拼头”的步骤#

Token 生成好、验证通过，最后一步是把它放进请求里——也就是拼成 Authorization: Bearer <JWT>。这个格式看似简单，手写却容易出错：少了空格、前缀拼错、cURL 里引号没转义、Fetch 里 headers 写错，都是常见的小坑。

星点 JWT → Authorization Header 把这件事自动化：输入 JWT，自动生成 Authorization: Bearer <token>，并输出 HTTP Header、cURL、JavaScript Fetch 与 JSON 四种格式，一键复制。Token 仅在浏览器本地参与拼接，不上传、不保存。

为什么是 Bearer#

大多数接口使用 Authorization: Bearer <JWT> 传递身份凭证。Bearer（持有者）表示”谁持有这个 Token，谁就被视为其声明的身份”。

前缀	用途
Bearer	携带 Token（如 JWT）
Basic	用户名密码的 Base64 编码，不属于 JWT 场景

所以本工具默认 Bearer；Basic 不做转换；如需其它前缀，可自定义填写。

四种输出格式#

格式	用途
HTTP Header	贴进 Postman / 抓包工具的请求头
cURL	直接贴进终端执行
JavaScript Fetch	贴进前端代码
JSON	贴进配置文件

每段独立一键复制，避免手动格式化出错。

怎么用（详细步骤）#

打开 JWT → Authorization Header；
粘贴 JWT（或从解析器 / 生成器带入）；
按需修改前缀（默认 Bearer）；
查看生成的四段结果；
复制需要的格式，粘贴到请求头、终端或代码中。

一个输出示例#

输入 Token 后，工具会生成类似：

1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

1
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." https://api.example.com

1
fetch("https://api.example.com", {
2
  headers: { Authorization: "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." }
3
})

Bearer Token 用在哪#

HTTP 请求头：Authorization: Bearer <token>，最标准的做法；
cURL / 脚本：调试接口时直接贴进终端；
前端代码：fetch / axios 里设置 headers.Authorization；
Postman 等工具：在 Auth 或 Headers 里填。

注意：尽量避免把 Token 放在 URL Query 里传递，因为 URL 会出现在日志、浏览器历史、Referer 中，容易泄露凭证。放在请求头里是更安全的做法。

一个安全小提醒#

Token 就是你的身份凭证。拼好请求头后，不要在公开场合（截图、群聊、commit）里粘贴完整 Token；用完及时失效。拼接本身在浏览器本地完成，工具不记录、不上传 Token，但 Token 一旦离开你的手，安全性就取决于你自己了。

常见问题（FAQ）#

Bearer 和 Basic 有什么区别？

Bearer 用于携带 Token（如 JWT）；Basic 是用户名密码的 Base64 编码，不属于 JWT 场景，本工具不做 Basic 转换。

为什么有些接口不用 Bearer？

格式取决于后端约定，有的用自定义前缀或独立字段。本工具支持自定义前缀，也可直接复制 Token 自行拼装。

Token 会被记录吗？

不会。拼接在浏览器本地完成，不产生网络请求，也不写入本地存储。

拼好之后怎么验证 Token 对不对？

回到 [JWT 在线解析](https://www.xingdian.net/app/jwt/parse/) 查看内容，或 [JWT 签名验证](https://www.xingdian.net/app/jwt/verify/) 校验签名。

为什么需要四种格式？

不同场景粘贴位置不同：抓包工具用 Header、终端用 cURL、前端代码用 Fetch、配置用 JSON。四选一复制即可。

什么时候需要自定义前缀？

当后端约定的鉴权方案不是标准 Bearer（例如用 `Token`、`JWT` 或自定义单词）时，可把前缀改成后端要求的值。

拼好的请求头可以直接测接口吗？

可以。复制 cURL 到终端执行，或复制 Header 贴进 Postman，即可对目标接口发起请求，验证 Token 是否被后端接受。

输出的 Fetch 代码是标准写法吗？

是。Fetch 输出为标准 JavaScript `fetch` 调用，带 `Authorization` 请求头，可直接贴进前端项目使用。

Token 能放在 URL 里传吗？

不建议。URL 会出现在日志、浏览器历史与 Referer 中，容易泄露凭证。更安全的做法是放在 `Authorization` 请求头里，本工具默认生成的就是这种形式。

总结#

Authorization Header 生成器补上了 JWT 工作流的最后一步：把 Token 拼成规范请求头，输出 Header / cURL / Fetch / JSON 四种格式。配合 JWT 生成器造 Token、JWT 在线解析核对，一条完整的本地调试链路就通了。

立即体验：访问 JWT → Authorization Header