よくある質問

よくある質問

無効な JSON をオンラインでフォーマットできますか？

はい。壊れた JSON を貼り付けて Repair & Format をクリックしてください。シングルクォート、末尾カンマ、JSON キーのクォート漏れ、コメント、Python 風の値などを先に修復してから、整形済みの出力を表示します。

壊れた JSON はどう整形すればよいですか？

安全に貼り付けられる最小サンプルから始めて、まず構文を修復し、その後に厳格な JSON パーサーで検証します。末尾カンマを含む場合は、最後のカンマを取り除いてから有効になった結果をフォーマットできます。

「Unexpected token」とは何ですか？

厳格な JSON でその位置に現れてはならない文字をパーサーが見つけた、という意味です。シングルクォート、スラッシュ、末尾カンマ、大文字の True などは、JavaScript・Python・AI 応答からコピーされた「ほぼ JSON」を示唆していることがよくあります。

JSON を JavaScript オブジェクトに変換できますか？

はい。入力が有効な JSON であれば、JavaScript では JSON.parse(jsonText) を使ってください。テキストが JavaScript のオブジェクトリテラルである場合は、まず厳格な JSON に修復してから解析してください。

データは安全ですか？

はい。本ツールは完全にブラウザ内で JavaScript として動作します。データが外部サーバーに送信されることは一切ありません。

Repair と Validate の違いは何ですか？

Repair はよくある誤りを許容し、有効な JSON を生成しようとします。Validate は厳格なパーサーを使い、エラーの正確な行と列を報告します。

詳細な使い方ガイド

多くの JSON フォーマッターはパーサーがエラーを投げると止まります。本ツールはその「通常のフォーマット前の一段階」を担います。つまり、ほぼ JSON を厳格な JSON に変換し、その上で整形して構造を確認しやすくします。だからこそ、「壊れた JSON をどう整形するか」を探しているときに役立ちます — 単に有効な応答を整形したいだけのときではなく。

安全に貼り付けられる、できるだけ小さな壊れた JSON から始めてください。テキストが JavaScript のオブジェクトリテラル、Python の断片、Markdown の応答、手で編集された設定、または JSON のように見えて厳格なパーサーでは落ちるログ出力に由来する場合は、Repair & Format をクリックしてください。修復パスは、よくある構文ミスを有効な JSON に正規化し、予測可能なインデントで出力するので、入れ子の配列やオブジェクトもレビューしやすくなります。

修復のあと、Validate をクリックします。検証は厳格なパーサーを使い、API クライアント・アプリ設定・DB マイグレーション・テストフィクスチャ・コマンドラインの例に出力をコピーする前の最後のチェックです。検証に失敗したら、行と列を確認し、ハイライトされたトークンを見て、入力と修復後の出力を見比べてください。修復は構文をきれいにするためのもので、値がアプリケーションの意味として正しいかどうかを判断するものではありません。

JSON が有効になった後にのみ Minify を使ってください。最小化された JSON は環境変数、クエリパラメーター、コンパクトなログ、ドキュメント内の小さなサンプルに便利です。コードレビュー・デバッグ・API テストでは、各キー・配列要素・入れ子の値が予測可能な行に並ぶため、整形済み出力の方が安全です。

JSON エラー辞典

末尾カンマ

} や ] の前の最後のカンマは、多くの JavaScript ツールでは受け付けられますが、JSON パーサーでは拒否されます。最後のプロパティや配列要素の後ろにある余分なカンマを取り除いてください。

JSON キーのクォート漏れ

name や active のようなオブジェクトのキーはダブルクォートで囲まれていなければなりません。{ name: "Ada" } を { "name": "Ada" } に変えてください。

シングルクォート

JSON 文字列はダブルクォートが必要です。'Ada' を "Ada" に置き換え、文字列内のアポストロフィにも注意してください。

Unexpected token

厳格な JSON 文法が許容しない位置に文字が現れた、というメッセージです。カンマ・スラッシュ・シングルクォート・大文字のブール値、または JSON ドキュメント末尾以降の余分なテキストなどが該当します。

Python リテラル

Python は True・False・None を使います。JSON は true・false・null を使います。

コメント

コメントは JavaScript や JSONC でよくありますが、有効な JSON ではありません。データを JSON パーサーに渡す前に // の行コメントと /* ブロックコメント */ を取り除いてください。

Markdown コードフェンス

LLM の応答はしばしば JSON を ```json フェンスで囲みます。解析や API への送信の前に、フェンスマーカーを取り除いてください。

各ツールに関する質問

JSON Fix — 無効な JSON はどう修復しますか？

壊れた JSON を JSON Fix に貼り付け、Repair & Format をクリックしてください。末尾カンマ、シングルクォート、クォートなしのキー、Python リテラル、コメント、Markdown コードフェンスを一度に修復します。

JSON Validate — 検証と解析の違いは？

解析は JSON を使える値に変換します。検証は単に解析可能だったことを確認するだけです。成功した JSON.parse そのものが検証 — 詳細は JSON Validator を参照してください。

JSON Viewer — ツリーが空になるのはなぜ？

ツリーは解析可能な JSON からしか組み立てられません。まず JSON Fix でよくある誤りを修復し、その後きれいになった結果を JSON Viewer に読み込ませてください。

JSON Diff — ソート済みと未ソートが同一と報告されるのはなぜ？

仕様上、JSON オブジェクトは順序を持ちません。JSON Diff は比較前にキーを正規化するため、本当の値の差分だけが表示されます。

JSON to TypeScript — 生成された型は実行時に検証されますか？

いいえ。JSON to TypeScript はコンパイル時のインターフェースを生成します。実行時検証は Zod と組み合わせるか、JSON Schema で形状を記述してください。

JSON Minify — 最小化でどれくらい節約できますか？

HTTP 圧縮前で通常 15〜50% です。サーバーがすでに Content-Encoding: gzip や br を送っている場合、minify による限界的な節約は小さくなります。

JSON Stringify — 二重エンコードされた JSON 文字列はどう復号しますか？

JSON Stringify で Unstringify をクリックするか、入力がエスケープされたクォートで始まる場合は JSON.parse を 2 回呼び出してください。

JSON ⇄ CSV — 入れ子オブジェクトはどう表現されますか？

入れ子のオブジェクトや配列はそれぞれ JSON テキストとしてセルに書き込まれ、可逆性が保たれます。詳細は JSON to CSV を参照してください。

JSON ⇄ XML — 値を XML 属性にするには？

キー名の前に @ を付けてください（例: @id）。要素のテキストは #text に入り、配列は繰り返し要素になります。詳細は JSON to XML を参照してください。

YAML — YAML の解析が失敗するのはなぜ？

ほぼ常にインデントの問題です — タブ文字（YAML はタブを禁止）か、兄弟要素のずれです。YAML フォーマッター に通すと、どちらも顕在化させ正規化できます。

Base64 — Base64 と Base64url の違いは？

標準の Base64 は + と / を使い、= でパディングします。URL セーフな Base64url はそれらを - と _ に置き換え、パディングを落とすので、URL や JWT 内でも安全です。詳細は Base64 を参照してください。

URL Decode — + が空白にデコードされないのはなぜ？

クエリ文字列では空白が +（フォームエンコーディング）または %20 として現れます。decodeURIComponent は + を空白に変換しません — フォームエンコーディングのデータなら、先に自分で置換してください。詳細は URL Decode を参照してください。

JWT Decode — 署名は検証されますか？

いいえ。JWT Decode はクレームを読みますが、署名は検証しません。必ずサーバー側で検証し、ライブラリには期待するアルゴリズムを正確に設定してください（alg: none を受け入れてはいけません）。

どのエラー記事を読めばいい？

正確なエラーメッセージが手元にあれば、対応する記事に直接ジャンプできます:

• 「Unexpected token < in JSON at position 0」 → fetch が HTML を返した
• 「Unexpected token u in JSON at position 0」 → undefined を解析してしまった
• 「Unexpected token o in JSON at position 1」 → オブジェクトが [object Object] として文字列化された
• 「Unexpected end of JSON input」 → 切り詰められた、または閉じられていない構造
• 「Unexpected non-whitespace character after JSON data」 → 完結した値の後に余分なデータ（NDJSON？）
• 「Unterminated string in JSON」 → 文字列が開かれたまま閉じられていない
• 「Bad escaped character in JSON」 → 無効なバックスラッシュエスケープ（例: \x、Windows のパス）
• 「Bad control character in string literal in JSON」 → 文字列内に生のタブ・改行・制御バイト
• 「Expected double-quoted property name…」 → 末尾カンマ
• 「[object Object] is not valid JSON」 → 解析前にオブジェクトが文字列化された
• どれかわからない？ → 概要記事から始めてください: JSON.parse Unexpected Token エラーの直し方

ローカル処理がプライバシーを守る仕組み

修復・検証・整形・最小化・コピーの各操作はすべてあなたのブラウザタブ内で実行されます。本ツールが JSON を処理するのにアップロード用エンドポイントは不要です。API サンプル・Webhook ペイロード・内部の設定スニペット・プライベートな識別子を含みうるデバッグ出力にとって、これは重要です。どのウェブサイトに例を貼り付けるときも秘密情報は事前に削除すべきですが、本ツールはコアの JSON ワークフローが「ローカルファースト」になるよう設計されています。

本サイトはページ周辺でホスティングログや解析スクリプトを使うことがあります（プライバシーポリシー参照）。これらの仕組みは、修復のためにエディターに貼り付けた内容を受け取るべきではありません。ペイロードに資格情報・アクセストークン・顧客レコード・本番のシークレットが含まれる場合は、デバッグ前に安全なプレースホルダーに置き換えてください。

JSON とは何か、なぜ厳格なのか

JSON は JavaScript Object Notation の略ですが、現代の JSON は言語非依存です。Python・Go・Java・PHP・Ruby・Rust・データベース・キュー・ログ基盤・ブラウザコードはどれも同じ JSON ドキュメントを読めます。文法が意図的に小さく作られているからです。この厳格さは有用です: JSON パーサーは関数・コンストラクタ・日付・コメント・式を実行しません。データだけを受け入れます。

トレードオフは、JavaScript のオブジェクトリテラル、Python の辞書、TypeScript の設定、Markdown の回答などからコピーされたテキストは見た目が似ていても無効な JSON のままだ、ということです。修復は、こうした「ほぼ JSON」を厳格なパーサーが受け入れられるデータに変換します。

修復済み JSON を使う前に

修復が成功したということは、テキストが有効な JSON 構文に変換できる、という意味です。エンドポイントやアプリケーションにとってペイロードが正しいことを保証するものではありません。本番で修復済み JSON を使う前に、必須フィールド・未知のキー・値の型・配列長・日付フォーマット・enum 値・null の扱い・識別子が文字列か数値かを確認してください。

ペイロードが権限・課金・データ削除・ユーザー可視の挙動を制御する場合は、修復後に既知の良好なサンプルやスキーマと比較してください。API 作業では、まず構文を検証し、次にビジネス上の契約を検証します。