🌀 cURL ⇄ fetch / axios / wget 转换
将 cURL 命令转换为各种语言和库的 HTTP 请求代码。保留 headers、cookies、body。
完全免费
无需注册
浏览器内完成
5 种语言
深色模式
支持的 cURL 选项
-X, --request
-H, --header
-d, --data
--data-raw
--data-binary
--data-urlencode
-u, --user
-b, --cookie
-A, --user-agent
-e, --referer
-F, --form
--compressed
-k, --insecure
-L, --location
-I, --head
📖 常见的坑
把 cURL 命令转换成 fetch / axios / Python requests / PHP / Go / Rust / wget / HTTPie 等 13 种代码，原样保留头部、Cookie 与请求体，处理全部在浏览器内完成。「原样保留」既是这个工具的价值，也是它最大的注意事项——从浏览器 DevTools 复制出来的 cURL，把你的登录会话一并带走了。而且浏览器发送的许多头部，并不是你的代码应该发送的。转换明明成功、贴过去却跑不通，多半就是这两件事之一。
| 情形 | 会发生什么 | 怎么处理 |
|---|---|---|
| 复制来的 cURL 原样带着你的凭据 | DevTools 的 Copy as cURL 会把该请求实际发送的全部头部都写出来——Cookie 头里是你的会话 ID，Authorization 里是你的访问令牌，都是明文。这串东西足以让人以你的身份登录。危险之处在于，这份 cURL 的形态天生就很容易被分享——作为复现步骤贴进工单、用 Slack 发给同事、写进博客文章，或者贴给 AI 问「为什么跑不通」。其中任何一种，都是把一个有效会话送了出去。而且它看上去只是一条长命令中的一段，粘贴的人根本不会察觉。 |
分享之前请删掉 Cookie 与 Authorization 那两行。本页的处理完全在浏览器内完成，粘贴到这里本身是安全的，但生成的代码里同样原样含有那些值——你把输出复制到别处的那一刻，问题就复活了。在实务上，要写调用 API 的代码，请先自己把认证部分重新搭一遍——正确的做法是使用为该 API 签发的 API 密钥或服务账号，而不是浏览器的会话 Cookie。如果已经分享出去了，请让那个会话失效（登出或轮换令牌）——「大概没人看到」不算处理。 |
| 把浏览器的头部原样搬进代码 | DevTools 复制出来的头部里，有很多是浏览器自己的事而非 API 的事——sec-ch-ua、sec-fetch-mode、Accept-Encoding、Connection、Content-Length、Host、Referer 等等。这些属于 HTTP 客户端自动管理的范畴，手工指定就会出问题——把固定的 Content-Length 搬过去，一改请求体就对不上；显式写上 Accept-Encoding: gzip，某些库便不再解压，还给你一堆原始压缩字节。在浏览器中运行还有更多：Origin、Referer、Cookie 等属于禁止头部，fetch 会悄悄丢弃它们——不会报错，于是你以为设置了，行为却变了。 |
转换之后，请把头部削减到最小。真正需要的通常只有五样：方法、URL、Content-Type、认证、请求体。先删，再跑，只把跑不通的那些加回来——按这个顺序做，你就知道哪些头部是真正必需的。唯有 User-Agent 偶尔确实需要（因为有些 API 会拒绝默认值）。另外，若要在浏览器里运行，请先确认 CORS——cURL 处在同源策略之外，因此「cURL 能成功的请求在 fetch 下失败」是正常现象。那是服务端 Access-Control-Allow-Origin 的问题，不是代码的问题，无论怎么改转换结果都解决不了。 |
| Shell 的引号把请求体改掉了 | cURL 命令建立在 shell 语法之上，因此同一条命令在不同 shell 下送达的内容并不相同。Windows 的 cmd.exe 不把单引号当作引用符号，于是 -d '{"a":1}' 会连引号字符一起送到服务器。在 PowerShell 5.1 中，curl 是 Invoke-WebRequest 的别名，cURL 的选项压根不适用。含非 ASCII 文本的请求体更麻烦：从 Windows 的 bash 发送时，某些环境会用本地代码页而不是 UTF-8 来编码——在服务端表现为乱码，而命令却报告成功。还有一点：-d 会把以 @ 开头的值解释为文件名，而且还会去掉换行——粘贴格式化过的 JSON 会被压成一行。 |
请把请求体放进文件，用 --data-binary @body.json 发送。--data-binary 会原样发送换行与字节编码，不给 shell 任何插手的余地——测试含非 ASCII 文本的 JSON 时，这是唯一可靠的办法。在 Windows 上，连扩展名一起写作 curl.exe，即便在 PowerShell 中也会启动真正的 cURL。更根本地说，cURL 是「跑一次确认一下」的工具，并不适合作为反复执行的操作手册——要留作流程，请把转换出来的代码提交进仓库。代码能做差分、能评审、能测试。 |
被转换的只是「一次请求」。真实使用 API 所需要的许多东西，根本没有出现在 cURL 命令里——重试、超时、限流应对、分页、错误处理、连接复用。把生成的代码原样放进生产，这些就全都缺席了。超时尤其如此：各语言的默认值差异极大，有的会无限等待，所以请务必显式设置。另一点：cURL 默认不跟随重定向（需要 -L），而许多 HTTP 库默认跟随——这是「同一个 URL 行为看起来却不同」的经典原因。另外，转换带有 -k / --insecure 的 cURL 时要格外小心——那个选项会关闭 TLS 证书校验，把这种状态的代码带进生产，就等于对中间人攻击不设防。证书报错请去修根因，而不是关掉校验。
📖 使用方法
-
1
从 DevTools 复制在 DevTools Network 标签右键 → Copy as cURL。
-
2
粘贴 cURL粘贴 cURL 命令。
-
3
选择目标语言从 13 种选项中选择;headers、cookies、body 都会保留。
❓ 常见问题
与 DevTools 的 Copy as cURL 兼容吗?
是。支持 Chrome/Firefox 生成的命令。
Python 想用 urllib 而不是 requests
选择"Python (urllib)"获取仅使用标准库的输出。
-F 参数如何处理?
会转换为每种语言的惯用表达。
如何管理 Authorization 令牌?
生产环境应存储在环境变量或 Secrets Manager 中。
🐛 此工具出现问题了吗？
免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。
✅
感谢您的反馈！
已送达运营者,将用于改进工具。