📝 TOML ⇔ JSON / YAML 変換ツール

TOML を JSON または YAML に双方向変換。Hugo の config.toml、Cargo.toml、pyproject.toml の編集に最適。

完全無料登録不要ブラウザ完結 5 言語対応ダークモード

🔒 プライバシーについて

・すべての処理はあなたのブラウザ内で完結します
・入力データは一切サーバーに送信されません

変換先フォーマット

JSON インデント

サンプル

TOML

JSON

自動変換

📖 つまずきやすいポイント

TOML を JSON または YAML へ、その逆方向にも変換します。Cargo.toml・pyproject.toml・Hugo の config.toml といった設定ファイルを読み解くのに使えます。処理はブラウザ内で完結します。TOML は「人が手で書き、人が読む設定ファイル」のために設計された形式で、データ交換のための形式ではありません — そのため JSON や YAML との間には、埋められない差がいくつかあります。

ケース	何が起きるか	どうする
JSON から TOML へ変換できない値がある	TOML には `null` がありません。これは実装の都合ではなく仕様上の判断で、設定ファイルにおいて「値が無い」は「そのキーを書かない」で表現すべきだ、という設計思想によります。したがって `{"timeout": null}` は TOML では表現できません。同じ理由で、型の混ざった配列 (`[1, "two", true]`) も多くの実装が受け付けません — TOML 1.0 では許されているのですが、パーサーの対応がまちまちです。API のレスポンスをそのまま TOML にしようとすると、まずこの 2 つで詰まります。	`null` のキーは変換前に取り除いてください — TOML の設計思想に合わせるなら、これが正しい対応です。「値が無い」ことを明示したいなら空文字列や `false` のようなそのキーにとって意味のある既定値を入れます。そもそも TOML をデータ交換に使わないでください — 用途が違います。TOML が向いているのは人が手で編集し、差分をレビューする設定ファイルで、機械が生成して機械が読むデータには JSON が適しています。「この構造は TOML で書きにくい」と感じたら、それは設定として複雑すぎるという信号かもしれません — ネストが 3 段を超えたら、設計を見直す価値があります。
同じ構造なのに変換結果が手書きと違って見える	TOML は同じデータを 3 通りの書き方で表現できます — テーブルヘッダ `[server]`、テーブルの配列 `[[bin]]`、そしてインラインテーブル `{ host = "x", port = 80 }` です。変換器はそのうちどれか 1 つを選んで出力するので、手で書いたものと構造は同じでも、見た目がまったく違うことがあります。混乱のもとになりやすいのがテーブルヘッダの「位置で決まる」性質で、`[server]` と書いた後のキーはすべて `server` に属します — 行の順序が意味を持つので、キーを 1 行動かすだけで所属するテーブルが変わります。	変換結果はどれも正しい TOML です — 手書きの見た目に寄せたいなら、変換結果を出発点にして手で整えるしかありません。そして、既存の設定ファイルをこのツールで往復させないでください — 決定的な理由はコメントが完全に消えることです。JSON にはコメントの概念が無いので、`Cargo.toml` や `pyproject.toml` を JSON 経由で整形すると、「なぜこの依存をピン留めしているのか」といった、そのファイルで最も価値のある情報が丸ごと失われます。このツールは「読み解く」ために使い、編集は元のファイルに対して直接行ってください。
日付が文字列になる・文字列が日付になる	TOML は日付時刻を第一級の型として持っています — `created = 1979-05-27T07:32:00Z` はクォート無しで書け、これは文字列ではなく日時の値です。JSON にはこの型が無いので、変換すると ISO 8601 の文字列になります。ここまでは自然な変換ですが、逆方向が問題です — JSON の `"2024-01-01"` を TOML に戻すと、実装によってはクォートが外れて日付型になり、意味が変わります。バージョンの日付や、日付の形をした ID (`"2024-01-01"` というリリース名など) を扱っていると、往復させただけで型が変わってしまいます。	日付の形をした文字列を扱うなら、往復させないでください。やむを得ない場合は、変換後の TOML を目で見て、意図した側にクォートが付いているかを確認してください — `created = 2024-01-01` は日付、`created = "2024-01-01"` は文字列で、この 1 組のクォートが型を決めています。設計の段階でこれを避けたいなら、日付として扱いたくない値には接頭辞を付けるのが有効です (`"v2024-01-01"` のように)。TOML の日時型は「ローカル日付」「ローカル時刻」「オフセット付き日時」の 3 種類があり、それぞれ意味が違います — タイムゾーンの情報が要る値には必ずオフセットを書いてください。

設定ファイルには、構造だけでなく「決まりごと」があります。pyproject.toml のキー名は PEP 518 と PEP 621 で定められており、[project] や [build-system] の構造を変えると pip install -e . が通らなくなります。Cargo.toml も同様で、[[bin]] はテーブルの配列でなければならず、[bin] と書くと別の意味になります。したがってこのツールは、他人が書いた設定ファイルの構造を読み解くために使うのが本来の用途で、整形や書き換えの経路として使うものではありません。もう 1 点、TOML には YAML のようなアンカーや参照の仕組みがありません — 同じ値を複数箇所に書く必要があり、それが冗長に見えることがありますが、これは「設定ファイルは上から順に読んで理解できるべきだ」という設計判断の結果です。共通化したいなら、TOML の中で解決しようとせず、生成する側のスクリプトで解決してください。

📖 使い方

1

TOML を貼り付け

左側のエディタに TOML を入力するか、サンプル (Hugo / Cargo / pyproject) を選択します。
2

変換先を選ぶ

JSON か YAML を選択。JSON ならインデント幅 (2/4) またはミニファイを指定できます。
3

双方向に変換

右側に変換結果が表示されます。逆方向 (JSON/YAML → TOML) も同様にリアルタイム変換できます。

❓ よくある質問

TOML とは何ですか？

Tom's Obvious, Minimal Language の略。INI に似た読みやすさで明確な型を持ち、Cargo (Rust)・Hugo・pyproject.toml で広く使われています。

日付や時刻はどう扱われますか？

TOML は datetime / date / time の各型を持ち、JSON 変換時は ISO 8601 文字列に、YAML では適切な型として出力されます。

YAML や JSON から TOML に逆変換できますか？

はい。右側のエリアに JSON または YAML を貼り付けて「→ TOML」ボタンを押すか、自動変換を有効にしてください。一部 TOML で表現できない構造 (混合配列など) は除外されます。

🔗 関連ツール

🐛 このツールで問題が発生しましたか？

完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。