YAML⇔JSON変換ツール
YAMLまたはJSONを貼り付けるだけで、もう一方の形式に変換できます。Docker Compose・Kubernetesの設定ファイル確認にも使えます。
最終更新：2026年9月9日 ／ 運営：sesebox（運営者情報）
すべてブラウザ内で変換され、サーバーに送信されることはありません。
name: shibahub tools: - json - yaml active: true
① このツールの使い方
JSONまたはYAMLを貼り付けると、もう一方の形式に変換されます。Docker Compose・Kubernetes・GitHub Actionsの設定ファイルはYAMLで書かれることが多い一方、APIのレスポンスやJavaScriptの設定はJSONが主流なので、どちらかの形式しか読み慣れていないときに変換して確認する用途で使えます。
② JSONとYAMLの主な違い
| 項目 | JSON | YAML |
|---|---|---|
| 構造の表現 | { } と [ ] で囲む | インデント（字下げ）で表現 |
| 文字列のクォート | 必須（ダブルクォート） | 省略できることが多い |
| コメント | 書けない | # で書ける |
| 読みやすさ | ネストが深いと括弧が増える | インデントで階層が見やすい |
JSONは括弧とカンマで構造を明示するため機械的に読み書きしやすく、YAMLはインデントで階層を表すため人間が目で見て編集しやすい、という向き不向きの違いがあります。
③ 変換でよくあるつまずきポイント
YAMLはインデントの半角スペースの数がずれると階層構造が変わってしまい、意図しない変換結果になることがあります。タブ文字はYAMLの仕様上使えないため、エディタの設定でタブがスペースに自動変換されているか確認してください。また、YAMLではyes・no・on・offが真偽値として解釈されることがあり、文字列のつもりで書いた値が意図せずtrue/falseに変換される場合があります。
他のデータ形式変換はCSV⇔JSON変換ツールでも用意しています。
④ YAMLだけが持つ「JSONに変換できない」書き方もある
YAMLには、同じ内容を複数箇所で使い回すための「アンカー（&）」と「参照（*）」という機能があります。一度&baseのように名前をつけたブロックを、別の場所で*baseと書くだけで複製できる仕組みで、設定ファイルの重複を減らすためによく使われます。この機能は変換時にJSON側では展開された状態（同じ内容がそのままコピーされた形）で出力されるため、JSON化したあとにアンカー部分だけをまとめて変更する、という使い方はできなくなる点に注意してください。
また、YAMLは---で区切ることで1つのファイルに複数のドキュメントをまとめて書ける「複数ドキュメント形式」にも対応していますが、JSONにはこの概念が無いため、複数ドキュメントのYAMLをそのままJSONに変換することはできません。
⑤ JSONはYAMLの書き方の一種でもある
あまり知られていませんが、JSONの構文（{と[を使った書き方）は、YAMLの仕様のサブセット（一部）として含まれています。そのため、多くのYAMLパーサーは、拡張子が.ymlのファイルにJSON形式の中身がそのまま書かれていても、正しいYAMLとして読み込めます。「YAMLで書く」＝「必ずインデント形式で書く」というわけではなく、JSONスタイルとインデントスタイルを1つのファイル内で混在させることも文法上は可能です（読みやすさの観点からはおすすめしません）。
⑥ バージョン番号など「数字に見える文字列」に注意
YAMLは値の型（文字列か数値か）を自動で判定するため、version: 1.10のように書くと、意図した文字列「1.10」ではなく数値の1.1として解釈され、末尾の0が消えてしまうことがあります。バージョン番号やIDのように、見た目が数字でも文字列として扱いたい値は、version: "1.10"のように明示的にクォートで囲むと、意図しない型変換を防げます。この変換ツールでも、クォートを外して貼り付けると同じ問題が起きるため、変換前の元データでクォートの有無を確認しておくと安全です。
⑦ 変換前にオンラインで貼り付けても大丈夫か
設定ファイルには接続情報やAPIキーなど、外部に出したくない値が含まれていることがあります。このツールは入力された内容をブラウザ上だけで変換しており、サーバーには送信していませんが、機密情報を含むファイルをどのツールに貼り付けるかは、業務のルールに従って慎重に判断してください。ダミーの値に置き換えてから構造だけ確認する、という使い方も安全です。
⑨ どちらの形式で書くべきか迷ったら
使うツール・フレームワーク側で形式が指定されている場合はそれに従うのが基本です。特に指定がなく自分で選べる場合は、人が手で編集する頻度が高い設定ファイルはYAML、プログラム同士でやり取りするデータはJSON、という使い分けが一般的な目安になります。
⑪ エディタの拡張機能でも予防できる
VS Codeなどのエディタには、YAML・JSONの構文エラーをリアルタイムで指摘してくれる拡張機能があります。普段から編集するファイルには導入しておくと、変換ツールに貼り付ける前の段階で構文ミスへ気づきやすくなり、余計な二度手間を確実に防げるようになります。
⑫ 結果がおかしいと感じたときの確認ポイント
変換エラーが出る場合、多くはJSONの末尾カンマかYAMLのインデント崩れが原因です。JSONは配列やオブジェクトの最後の要素の後にカンマを付けるとエラーになります。YAMLは同じ階層の項目のインデント幅（スペースの数）が揃っていないと、構造の解釈がずれてエラーになったり、意図しないネストになったりします。
コメントは変換後も残りますか？
YAMLのコメント（#で始まる行）はJSONの仕様上表現できないため、JSONに変換すると失われます。
yes/noなどの値が真偽値になってしまいます
YAMLの仕様上、yes・no・on・offなどは真偽値（true/false）として解釈されます。文字列として扱いたい場合はクォートで囲んでください。
タブ文字でインデントしてもいいですか？
YAMLの仕様上タブ文字は使えません。スペースでインデントしてください。