🌀 cURL ⇄ fetch / axios / wget 変換
cURL コマンドを各言語・各ライブラリの HTTP リクエストコードに変換します。ヘッダー・Cookie・ボディすべて保持。
対応している cURL オプション
🔗 関連ツール
📖 つまずきやすいポイント
cURL コマンドを fetch / axios / Python requests / PHP / Go / Rust / wget / HTTPie など 13 種類のコードに変換します。ヘッダー・Cookie・ボディをそのまま保持し、処理はブラウザ内で完結します。「そのまま保持する」ことがこのツールの価値であり、同時に最大の注意点です — ブラウザの DevTools からコピーした cURL には、あなたのログインセッションがそのまま入っています。そしてブラウザが送っていたヘッダーの多くは、コードから送るべきものではありません。変換は成功するのに、そのまま貼ると動かないのは、たいていこの 2 つが原因です。
| ケース | 何が起きるか | どうする |
|---|---|---|
| コピーした cURL に認証情報がそのまま入っている | DevTools の Copy as cURL は、そのリクエストが実際に送った全ヘッダーを書き出します — Cookie ヘッダーにはセッション ID が、Authorization にはアクセストークンが、そのまま平文で入っています。これは「あなたとしてログインできる文字列」です。危険なのは、この cURL が共有されやすい形をしていることです — 再現手順としてチケットに貼り、Slack で同僚に送り、ブログ記事に載せ、AI に「なぜ動かないか」と聞くために貼り付けます。そのどれもが、有効なセッションを外に出す行為です。しかも見た目には長いコマンドの一部にしか見えないので、貼る側が気付きません。 |
共有する前に Cookie と Authorization の行を削ってください。 このページの処理はブラウザ内で完結するのでここに貼ること自体は安全ですが、生成されたコードにも同じ値がそのまま含まれます — コピーして別の場所に貼る瞬間に、同じ問題が復活します。実務としては、API を叩くコードを書くなら、まず認証だけを自分で組み直してください — ブラウザのセッション Cookie ではなく、その API 用に発行した API キーやサービスアカウントを使うのが正しい形です。すでに共有してしまったなら、そのセッションを無効化 (ログアウトまたはトークンのローテーション) してください — 「たぶん誰も見ていない」は対処になりません。 |
| ブラウザのヘッダーをそのままコードに持ち込む | 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・認証・ボディの 5 つだけです。削ってから動かして、動かなくなったものだけを戻す — この順序でやると、どのヘッダーが本当に必要かが分かります。User-Agent だけは例外的に必要なことがあります (既定値を弾く API があるため)。そしてブラウザで動かすなら、CORS を先に確認してください — cURL は同一オリジンポリシーの外側にいるので、cURL で成功したリクエストが fetch で失敗するのは正常です。これはコードの問題ではなくサーバー側の Access-Control-Allow-Origin の問題で、変換をどう直しても解決しません。 |
| シェルのクォートでボディが変わってしまう | cURL コマンドはシェルの構文の上に乗っているので、同じコマンドでもシェルによって届く中身が変わります。Windows の cmd.exe はシングルクォートを引用符として扱わないため、-d '{"a":1}' はクォート記号ごとサーバーに届きます。PowerShell 5.1 では curl が Invoke-WebRequest の別名なので、そもそも cURL のオプションが通りません。日本語を含むボディはさらに厄介で、Windows の bash から送ると、環境によっては UTF-8 ではなく Shift-JIS で送られます — サーバー側では文字化けとして現れますが、コマンドは成功します。もうひとつ、-d は値の先頭が @ だとファイル名として解釈し、さらに改行を取り除きます — 整形済み JSON を貼ると 1 行に潰れます。 |
ボディはファイルに置き、--data-binary @body.json で送ってください。 --data-binary は改行も文字コードもそのまま送るので、シェルの解釈が入り込む余地がありません — 日本語を含む JSON をテストするときは、これが唯一確実な方法です。Windows では PowerShell からでも curl.exe と拡張子まで書けば本物の cURL が起動します。そもそもの話として、cURL は「一度動かして確かめる」ための道具で、繰り返し実行する手順書には向きません — 手順として残すなら、変換したコードのほうをリポジトリに置いてください。コードなら差分が読め、レビューでき、テストできます。 |
変換されるのは「1 回のリクエスト」だけです。実際の API 利用に必要なものの多くは、cURL コマンドには写っていません — 再試行、タイムアウト、レート制限への対応、ページング、エラーハンドリング、接続の再利用。生成されたコードをそのまま本番に置くと、これらが全部欠けた状態になります。とくにタイムアウトは、既定値が言語ごとに大きく違い、無限に待つものもあるので、必ず明示的に設定してください。もうひとつ、cURL は既定でリダイレクトを追いません (-L が必要) が、多くの HTTP ライブラリは既定で追います — 同じ URL なのに挙動が違って見える原因の定番です。そして -k / --insecure が付いた cURL を変換した場合は要注意です — これは TLS 証明書の検証を無効にするオプションで、その状態のコードを本番に持ち込むと、中間者攻撃に対して無防備になります。証明書エラーは、検証を切るのではなく原因を直してください。
📖 使い方
-
1
DevTools からコピーChrome / Firefox の DevTools > Network タブで任意のリクエストを右クリック → Copy as cURL を選択します。
-
2
cURL を貼り付け入力欄に cURL コマンドをペーストします。複数行の \ 区切りも認識されます。
-
3
ターゲット言語を選択fetch・axios・Python requests・Go net/http など 13 種類から選ぶと、ヘッダー・Cookie・ボディを保持したまま変換されます。
❓ よくある質問
DevTools の Copy as cURL と完全互換ですか?
Python で requests ではなく urllib で出力したい
multipart/form-data (-F) はどう扱われますか?
Authorization ヘッダのトークンはどこで管理すべき?
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。