JSON ↔ YAML 変換無料・登録不要
JSON と YAML を相互変換。Kubernetes・Ansible・GitHub Actions の YAML、API レスポンス JSON の双方向変換に対応。リアルタイム変換・ブラウザ完結。
- JSON は厳格構文（ダブルクォート必須・末尾カンマ NG）、YAML はインデント構文（タブ不可・スペースのみ）
- Kubernetes / Ansible / GitHub Actions の YAML、API レスポンス JSON の相互変換に便利
- 結果はリアルタイム変換。エラーがあれば赤枠で表示
- すべてブラウザ完結（入力データはサーバーに送信されません）
良いJSON ↔ YAML 変換の判断基準
設定ファイルでよく使われるYAMLと、APIデータでよく使われるJSONを行き来するときに使います。変換結果が出たら、下の基準で「構造と型が意図どおりか」を確認してから貼り付け先に持っていきます。
インデント（字下げ）が崩れていないか
YAMLはインデントの深さがそのまま構造の意味になります。変換結果を貼り付けるときにインデントがずれると、エラーではなく「別の階層のデータ」として通ってしまうことがあるので、目で見比べて確認します。
数値・真偽値の型が意図どおりか
YAMLでは引用符のない値が数値や真偽値として解釈されることがあります。たとえば 1.0 は数値、"1.0" は文字列です。文字列として扱いたい値には引用符を付けます。
yes / no などの語の扱いを確認したか
YAMLの処理系によっては、yes / no・on / off といった語が真偽値として解釈されることがあります。文字列のつもりの値が true / false に変わっていないか、変換結果を目で確認します。
YAMLにタブ文字が混ざっていないか
YAMLの字下げに使えるのはスペースだけで、タブは使えません。エディタからコピーしたデータにタブが混ざっているとエラーになるため、エラー時はここも疑います。
逆方向に変換し直して元に戻るか確かめたか
心配な場合は、変換結果をもう一度逆方向に変換して、元のデータと同じになるかを確認します。型の変化や値の欠落に気づくための簡単なチェックです。
機密の設定ファイルを貼る前に所属組織のルールを確認したか
設定ファイルには接続情報やキーが含まれがちです。外部のツールに貼ってよいデータかどうか、所属組織のルールを先に確認します。
ありがちな失敗例（NG → 改善）
NGバージョン番号を version: 1.10 と引用符なしで書き、数値として解釈されて意図と違う値になる。
改善version: "1.10" のように引用符を付けて、文字列として固定する。
→ 引用符のない 1.10 は数値として解釈され、末尾のゼロが落ちることがあります。バージョン番号など「数字の見た目をした文字列」は引用符で守ります。
NG変換したYAMLをエディタに貼り付けたときにインデントがずれ、子要素が別の階層として扱われる。
改善貼り付け後に、インデントの深さが変換結果と同じかを目で確認する。
→ YAMLはインデントが構造そのものです。ずれてもエラーにならず「別の意味のデータ」として通ることがあり、気づきにくい崩れ方をします。
NG文字列のつもりで書いた no という値が、真偽値の false として扱われてしまう。
改善"no" のように引用符を付けて、文字列であることを明示する。
→ yes / no / on / off を真偽値として解釈するYAML処理系があります。短い語ほど引用符を付けておくと安全です。
JSON ↔ YAML 変換の使い方
- 1テキストを入力またはペーストします
- 2「変換する」ボタンをクリックします
- 3結果を確認してコピーします
よくある質問
JSON ↔ YAML 変換は無料ですか？
はい、完全無料でご利用いただけます。会員登録も不要です。
スマートフォンでも使えますか？
はい、スマートフォン・タブレット・PCなど、ブラウザがあればどのデバイスでもご利用いただけます。
入力したコードやデータは安全ですか？
はい、入力データはブラウザ上で処理され、サーバーに送信されません。安心してご利用ください。
関連ツール
JSON ↔ YAML 変換について
JSON と YAML が混在する現場で書き直しが発生するとき
API レスポンスは JSON、設定ファイル（Kubernetes / Ansible / GitHub Actions / Docker Compose）は YAML、というように 2 つの形式が混在する開発現場で「この JSON を YAML に書き直したい」「先輩から渡された YAML を JSON で API に渡したい」というニーズが頻発します。本ツールはペーストするだけで両形式を相互変換し、エラーがあれば赤枠で明示します。
処理はブラウザの中で完結します。編集部が3パターンを流しながら通信を見張った範囲では、処理中に生成 AI の API を呼ぶ通信は1件も発生しませんでした。
Kubernetes・GitHub Actions・OpenAPI で形式をそろえる作業
【1. Kubernetes マニフェストの作成・編集】既存の JSON 定義を YAML に変換して `kubectl apply -f` で適用。
【2. GitHub Actions ワークフロー編集】Marketplace のサンプル JSON を YAML に変換して `.github/workflows/*.yml` に貼り付け。
【3. API ドキュメント作成】OpenAPI 仕様で受け取った JSON を YAML 形式に変換して可読性を上げる。
【4. Ansible Playbook 作成】Roles の変数定義 JSON を YAML に変換して `vars/main.yml` に配置。
いずれも、変換そのものより「変換後に型が変わっていないか」を見る手間の方が大きい作業です。後の項目で、その型が実際にどう変わったかを記録しています。
本ツールの特徴
1. 双方向対応: JSON→YAML / YAML→JSON 両方向に対応、ボタンで即切替。 2. リアルタイム変換: 入力中にも即変換結果が表示されます。 3. エラー箇所表示: パースエラー時は赤枠で原因（不正な構文・インデントミス等）を表示。 4. インデント選択: YAML / JSON ともに 2 スペース / 4 スペースを選択可能。 5. ブラウザ完結: すべてクライアントサイドで処理。入力データはサーバーに送信されません（機密設定ファイルでも安心）。
この5点は、編集部が画面と処理を確認した範囲では表示のとおりでした。変換ボタンのほかに、入力と出力を入れ替えるボタンと、サンプルを読み込み直すボタンが並んでいます。
既定サンプルの JSON を YAML に変換した実処理結果
画面を開いた時点で入っているサンプルは、name・version・tools・owner の4項目を持つ JSON です。tools は slug と category を持つオブジェクトが2つ並んだ配列になっています。
これを JSON → YAML にかけると、name と owner はそのまま「キー: 値」の1行になり、tools は配列の各要素が2スペース字下げのハイフン付きで並び、その中の category はさらに深い字下げで揃いました。
注目したのは version です。JSON 側では文字列として "1.0" と書かれており、YAML 側の出力も version: '1.0' と引用符が付いた形で出ました。文字列は文字列のまま運ばれます。この向き（JSON から YAML）では、型が勝手に変わる場面は今回のサンプルでは起きませんでした。
version: 1.10 と yes / no を YAML から JSON にした実処理結果
型が変わるのは逆向きでした。YAML → JSON に切り替えて、name: sample のほかに version: 1.10、answer: no、enabled: yes、code: "0123" の4行を書いた YAML を入れました。引用符を付けたのは code だけです。
返ってきた JSON は、version が 1.1、answer が "no"、enabled が "yes"、code が "0123" でした。
つまり3つのことが同時に起きています。1つ目は、引用符のない 1.10 が数値として読まれ、末尾のゼロが落ちて 1.1 になったこと。バージョン番号を書いた設定ファイルでは、意味が変わってしまう桁落ちです。JSON 側には 1.1 という数値しか残らないので、元の 1.10 という表記に戻す手がかりはありません。2つ目は、no と yes が真偽値ではなく文字列のままだったこと。YAML の一部の実装では false / true に化けますが、本ツールが使っている読み取りライブラリの既定では化けませんでした。3つ目は、引用符を付けた "0123" は文字列のまま、先頭のゼロも残ったことです。
これは今回試した3パターンで見えた範囲で、どんな YAML でも同じ型解釈になる保証ではありません。桁や先頭ゼロが意味を持つ値は、変換の前に引用符を付けておくのが確実です。
タブで字下げした YAML を入れたときのエラー表示
わざと仕様違反の YAML も入れました。1行目に name: sample、2行目をタブ1つで字下げして child: value と書いた入力です。YAML はタブでの字下げを認めていません。
出力欄は赤枠の「パースエラー」に変わり、「tab characters must not be used in indentation (2:1)」というメッセージが出ました。その下には入力が行番号付きで再掲され、1行目に name: sample、2行目にタブを矢印記号で可視化した child: value が並び、さらに下の行で位置を指す印が2行目の先頭を指していました。最後に「入力 YAML の構文を確認してください（インデント・コロン後の空白）」という日本語の補足が付きます。
エラー文の本体は英語ですが、行番号と列番号（2:1）が付き、該当行が再掲されるので、どこを直せばよいかは見て分かります。JSON 整形のようにエラーが「先頭から何文字目」で示されるのとは違い、こちらは行で示されます。
設定ファイルに戻す前に型と引用符を確認する基準
1つ目: JSON のダブルクォート忘れ → JavaScript オブジェクトリテラル形式（シングルクォート可）と JSON（ダブルクォート必須）は別物。エラー時は引用符を確認。
2つ目: YAML のタブ使用 → YAML 仕様ではタブ NG（スペースのみ）。エディタの設定でタブをスペースに自動変換する設定にしておきましょう。
3つ目: YAML の前置記号 `---`（ドキュメント区切り）の有無 → 単一ドキュメントなら省略可、複数ドキュメント時は必要。
4つ目: 数値の自動型変換 → YAML では `version: 1.0` が float、`version: "1.0"` が string になります。意図しない型変換を避けたい場合は引用符を明示してください。
変換結果を本番の設定ファイルに戻す前に、人が見るのは3点です。1つ目は、桁が意味を持つ値（バージョン番号・電話番号・商品コード）が変換後も元の桁のままか。2つ目は、yes / no / on / off のように真偽値と読めてしまう語を、受け取る側がどちらの型で期待しているか。3つ目は、字下げの深さです。字下げのずれはエラーにならず「別の階層のデータ」として通ってしまうため、変換前後を並べて見るのが確実です。
手で書き直す方法・エディタの拡張との使い分けと、向かない用途
同じ変換は、エディタの拡張機能やコマンドラインの変換ツールでもできます。それらは手元のファイルをまとめて処理できる代わりに、導入と設定が要ります。本ツールは、開いて貼るだけで結果が出て、入力と出力を入れ替えて往復も試せるので、1ファイルだけ形式を変えたい、型の変わり方を確かめたい、といった単発の作業に向いています。
向かないのは3つです。1つ目は、複数のドキュメントを --- で区切った YAML をまとめて扱う用途。2つ目は、コメント付きの設定ファイルを往復させる用途で、YAML のコメントは JSON に持っていけません。3つ目は、鍵やパスワードが書かれた設定ファイルです。送信されない作りであっても、画面に出す時点で肩越しに見られる可能性は残ります。