JSON YAML 変換ツール

JSON と YAML は同じデータを表す二つの書き方です

JSON はオブジェクトを波括弧 { }、配列を角括弧 [ ] で囲み、キーと文字列を二重引用符で囲みます。YAML は同じ構造をインデントと行頭のハイフン(-)で表し、引用符はたいてい省略します。JSON のオブジェクトは YAML ではマッピング、配列はシーケンスになります。数値・真偽値・null もそれぞれ対応します。YAML 1.2 の仕様書は、この版の主な目標が YAML を JSON の厳密な上位集合にすることだったと述べており、そのため正しい JSON 文書の大半はそのまま YAML としても読めます。

この変換ツールでは、二つの欄のどちらも編集できます。JSON 欄を直すと YAML 欄が作り直され、YAML 欄を直すと JSON 欄が作り直されます。中央の矢印は、いまどちらの欄が元になっているかを示します。行をクリックするか矢印キーで移動すると、反対側の欄で同じ値を持つ行が強調され、下のパス行に owner › name のような位置と値の種類が表示されます。インデントだけでは、どの項目の下にある行なのか分かりにくい長い YAML で特に役立ちます。

JSON と YAML を行き来する場面

人が手で編集する設定ファイルは YAML、プログラム同士がやり取りするデータは JSON、という使い分けがよくあります。そのため、一つの作業の中で両方の形式を行き来することになります。

• Kubernetes のマニフェスト: Kubernetes のドキュメントは、設定ファイルを JSON ではなく YAML で書くことを勧めています。どちらでも動作しますが、人が読みやすいという理由です。クラスターから JSON で取得したリソースを YAML ファイルに直して保存するとき、逆に YAML のマニフェストを JSON しか受け付けない API やスクリプトに渡すときに変換が必要になります。
• Docker Compose・GitHub Actions: どちらのツールも設定は YAML でしか受け付けません。サンプルや API レスポンスが JSON のときは YAML に書き換えて貼り付けることになり、その際に引用符を落とすと値の型が変わってしまうことがあります。
• 検証と比較: JSON Schema の検証ツールや jq のように JSON を受け取るツールで YAML の設定を確認するには、先に JSON に変換する必要があります。アンカーやマージキーの多い Compose ファイルは、JSON に展開するとサービスごとに実際にどの値が入るのかが一目で分かります。
• 読み込む前に落とし穴を確認: 同じ YAML でも、読み込むプログラムが YAML 1.1 方式だと no は false に、0755 は 493 に変わります。設定を配布する前に、下の解釈チェックでそうした値がないか確認できます。

使い方

1. 手元にある JSON か YAML の欄に貼り付けます。「開く」ボタンかドラッグ&ドロップで .json・.yaml・.yml ファイルを開くと、拡張子に合った欄に入ります。
2. 反対側の欄に結果がすぐ表示されます。結果の欄を編集すると、そちらが元になって最初の欄が作り直されます。
3. 行を選ぶと反対側で同じ値の行が強調され、横に並べた画面では二つの行の間に接続線が引かれます。片方をスクロールすると、もう片方も同じ位置に追従します。
4. 欄の上のオプションで、インデント(JSON は2スペース・4スペース・1行、YAML は2スペース・4スペース)、YAML の解釈基準(1.2・1.1)、配列を複数の YAML ドキュメントに分けるかどうかを選びます。
5. 欄の下のボタンでコピーまたはファイルに保存します。開いたファイルが app.yaml なら、JSON は app.json として保存されます。

YAML 1.1 と 1.2 で読み方が変わる値

YAML は、引用符なしで書かれた値の型を文字の形から判断します。ところが、その規則は版によって異なります。YAML 1.2 の Core スキーマは、真偽値を true・false(大文字小文字の違いを含む)だけに限り、8進数は 0o で始まる表記だけを受け付けます。それ以前の YAML 1.1 の型規則では、yes・no・on・off・y・n を真偽値、0 で始まる整数を8進数、コロンでつないだ数字を60進数、2024-03-01 の形を日付として読みます。逆に、1.1 の浮動小数点の規則には小数点が必要なので、1e5 は 1.1 では文字列になります。

問題は、いまも 1.1 方式で読むプログラムが多いことです。Python の PyYAML は、自身を完全な YAML 1.1 パーサーと説明しています。Go の yaml v3 は 1.2 の大部分に従いますが、8進数は 1.1 と同じく 0777 の形で読み書きし、yes・no・on・off は真偽値型に格納するときだけ真偽値として受け付けます。Kubernetes のドキュメントも、真偽値には true か false だけを使い、yes・no・on・off は使わないよう述べ、真偽値に見える値は引用符で囲むことを勧めています。Docker Compose のドキュメントも、ポートを HOST:CONTAINER の形式で書くときは、YAML の60進数と衝突しないよう、常に引用符で囲んだ文字列にするよう案内しています。

最後の列は、JSON で文字列だった値を YAML で書くときの形です。二つの版のどちらか一方でも文字列以外として読まれる可能性があれば、二重引用符で囲みます。8080:80 は後ろの 80 が60進数の1桁(0〜59)を超えるため、どちらの版でも文字列になり、引用符は要りません。一方、2222:22 のように後ろが 59 以下のポートは、1.1 では数値になります。

YAML 欄が元になっているとき、下の解釈チェックは、文書の中で二つの版が異なる読み方をする値をすべて探し、行番号とともに表示します。チップを押すとその行に移動します。解釈基準を 1.1 に切り替えると JSON の結果も 1.1 の規則で作り直されるので、PyYAML のようなプログラムが実際に受け取る値を事前に確認できます。

YAML だけにある機能の変換結果

JSON を YAML に変換するときは、キーの順序を入力のとおりに保ちます。ブラウザー標準の JSON パーサーは、"2024" のように整数の形をしたキーをオブジェクトの先頭に移してしまうため、この変換ツールでは順序を保つ独自のパーサーで JSON を読みます。改行を含む文字列は | ブロックで、空のオブジェクトと空の配列は {}・[] で書き出します。

数値は書かれた文字のまま移します

JSON の仕様(RFC 8259)は、倍精度(IEEE 754 binary64)を超える精度を期待しない実装どうしであれば、数値を円滑にやり取りできると説明しています。ブラウザーも数値をこの方式で扱うため、一般的な変換ツールでは 9007199254740993 が 9007199254740992 に、4.50 が 4.5 に変わってしまいます。この変換ツールは数値を計算せず、書かれた文字をそのまま移すので、そうした変化は起きません。YAML 側の 0o17 や 0x1F のように JSON にない表記だけは、同じ値の10進数に変えます。

例外が一つあります。JSON の 1e5 は YAML 1.2 では数値ですが、YAML 1.1 では小数点がないため文字列になります。そのため JSON → YAML では、指数表記を 1.0e+5 のように小数点と符号を付けて書きます。どちらの版もこの文字列を数値 100000 として読みます。書き換えた数値は解釈チェックに表示されます。

よくある間違い

• インデントにタブ: YAML の仕様は、タブの扱いがシステムによって異なるため、インデントにタブ文字を使ってはならないと定めています。エディタでタブをスペースに置き換えてください。
• コロンの後の空白: port:8080 はキーではなく、一つの文字列です。キーと値の間には、port: 8080 のようにコロンの後に空白が必要です。
• 同じキーを2回: YAML の仕様はマッピングのキーが一意であるべきと定め、JSON の仕様は名前が重複したオブジェクトを受け取ったプログラムの動作は予測できないと警告しています。この変換ツールは、どちらの場合でも重複したキーをエラーとして知らせます。YAML の 1: と "1": も JSON では同じキーになるため重複します。
• JSON の緩い書き方: 最後の要素の後ろのカンマ、シングルクォート、引用符のないキー、// のコメントは標準の JSON ではありません。JSON5 や JSONC で書いた設定は、こうした部分を直してから入力してください。
• GitHub Actions の on:: ワークフローの on: キーは、YAML 1.2 では文字列 "on" ですが、1.1 方式のパーサーでは真偽値 true になります。ワークフローファイルを Python スクリプトで読んで編集するとき、キーが消えたように見えるのはこのためです。
• 時刻・ポートの形をした値: 18:30 や 2222:22 は、1.1 では60進数の数値になります。時刻とポートは引用符で囲んでおくのが安全です。

制限と注意

• 入力は 5 MB(5,242,880バイト)まで、結果は 10 MB まで変換します。ファイルは UTF-8(BOM 付きを含む)と UTF-16 の BOM 付きファイルを開けます。
• YAML のコメントや引用符の形、空行は、作り直すときに残りません。YAML を元にして JSON 欄を編集すると YAML が新しく書き出されるので、コメントがあった YAML は、ステータス行の「元に戻す」で一度だけ復元できます。
• CloudFormation の !Ref のようなユーザー定義タグは外して値だけを移します。CloudFormation が JSON で使う {"Ref": …} の形には変換しません。
• エイリアスの展開量が極端に大きい場合(エイリアス一つがさらにエイリアスの束を指すような場合)は、リソース枯渇を防ぐために中断します。
• YAML 1.1 の解釈は、yaml.org の 1.1 型規則に従います。実際の 1.1 方式のプログラムとは異なる境界もあります。たとえば y・n はこの規則では真偽値ですが、PyYAML は文字列として読みます。JSON → YAML の結果は、こうした値をすべて引用符で囲むので、どちらで読んでも文字列のまま残ります。
• 変換が扱うのは構文だけです。Kubernetes や Compose が要求するキー名や値の種類が正しいかどうかは、各ツールの検証コマンドで確認してください。

出典

• 01YAML — YAML Ain't Markup Language version 1.2.2§1.2 JSON の厳密な上位集合が主な目標、§3.2.1.1 マッピングのキーは一意、§6.1 インデントにタブ禁止、§10.3.2 Core スキーマ(null・bool・int・float の解釈表) — 2026-10-20 確認
• 02YAML 1.1 の型 — Boolean, Integer, Floating-Point, Timestamp, Merge Keybool(y・yes・on など)、int(8進数 0…、60進数)、float(小数点が必須、指数には符号)、timestamp、merge(<<)の規則 — type/int.html・float.html・timestamp.html・merge.html も併せて
• 03IETF — RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format§4 名前は一意であるべき(SHOULD)、重複すると動作は予測不能、§6 binary64 の精度と相互運用性、§8.1 UTF-8
• 04Kubernetes — Configuration Overview設定は JSON より YAML で、真偽値は true・false だけ、yes・no・on・off は使わない、真偽値に見える値は引用符で囲む
• 05Docker Docs — Compose file reference: services(ports)HOST:CONTAINER は YAML の60進数と衝突しないよう、常に引用符で囲んだ文字列で
• 06Docker Docs — Fragmentsアンカー(&)・エイリアス(*)と YAML のマージ型(<<)を使う Compose ファイル
• 07go-yaml v3 READMEYAML 1.2 の大部分に対応、1.1 の真偽値は真偽値型として読むときだけ、8進数は 1.1 と同じ 0777
• 08PyPI — PyYAML"complete YAML 1.1 parser"
• 09yaml (JavaScript) ドキュメントこの変換ツールが使うパーサー(2.9.1、ISC)。エイリアス展開の上限、マージキーは 1.2 仕様にない 1.1 の機能
• 10GitHub Docs — Workflow syntax for GitHub Actionsワークフローファイルは YAML 構文、拡張子は .yml または .yaml

よくある質問

あわせて使いたいツール