ツール利用 FAQ:データ、ファイル、エクスポート
要点:データはアップロードされるのか、どれくらいのファイルが動くのか、何かローカルに保存されるのか、なぜ日本語がエスケープになるのか。オンライン JSON ツールの実際の境界を十の質問で明示します。

要点:パース、整形、diff、クエリはすべてブラウザ内で動き、オフラインでも動き続けます。機密データを扱った後は localStorage の履歴を消し、10 MB を超えるならファイルをブラウザに貼らずコマンドラインのストリーミングツールに切り替えましょう。
機密ペイロードをオンラインツールに貼る前に、どこへ行くかを知りましょう。この記事はツールの実行時の振る舞いだけを扱い、構文は扱いません。
1. データとプライバシー
オンライン JSON フォーマッタはデータをサーバーにアップロードしますか?
いいえ。パース、整形、圧縮、diff、クエリはすべてブラウザで起こり、ページは貼り付けたものをアプリケーションサーバーへ決して送りません。
オンラインツールがデータをアップロードするかは、プライバシー声明を読まなくても、ブラウザのネットワークパネルで十分です。
- 開発者ツールを開き、Network パネルに切り替え、ログの保持を有効にします。
- JSON を貼り、「整形」をクリックします。
- 新しい XHR か fetch リクエストが現れるか、そのボディにあなたの内容が含まれるかを見ます。
本当にローカルなツールなら、この手順は静的資産のリクエストしか示しません。逆に、整形の一回でボディが元のテキストである POST /api/format が生まれるなら、ページが何と言おうとデータはすでにブラウザを離れています。
このサイトのすべてのツールは純フロントエンド実装で、ビルド出力にサーバー API は含まれません。オフラインにした後、キャッシュに当たる再読み込みはなお動きます。 これも「完全にローカル」かどうかを見分ける最も直接的な方法です。
オフラインでも使えますか?
はい。ページが一度読み込まれていれば。
サイトの資産は初回訪問時にブラウザキャッシュへダウンロードされるので、その後ネットワークがなくても整形、圧縮、JSON5 変換、 JSONPath クエリは動き続けます。ネットワーク依存の機能だけが失敗します。新しいバージョンの確認やデスクトップインストーラのダウンロードなどです。
オフラインのテストは「データが決して離れない」ことを検証する良い方法でもあります。切断した瞬間にすべてが壊れるなら、すべての操作がサーバーと話していたのです。
データはローカルに保存されますか?どう消しますか?
保存されますが、現在のブラウザの localStorage に限られ、履歴と UI 設定だけです。
- 履歴:最後に処理した 100 件を新しい順に保存し、前に貼ったデータを呼び出すのに使います。
- UI 設定:テーマ、言語、インデントの好みなど。
- 保存されないもの:ファイル自体、アップロード記録、身元を運ぶもの。
消し方は三つで、狭い順から広い順です。
| 方法 | 範囲 | 使うとき |
|---|---|---|
| 履歴ページの「履歴を消去」 | 履歴だけを削除し、設定は保つ | 機密データを扱った後 |
開発者ツールで localStorage.clear() |
このサイトのローカルデータすべて | 異常な設定の診断 |
| ブラウザのこのサイトの「閲覧データを消去」 | Cookie、キャッシュ、ストレージをまとめて | 共有マシンを使う前 |
共有マシンで本番データを扱うときは、タブを閉じるだけでなく終わったら履歴を消してください。localStorage はタブを閉じても消えません。
日本語が \u4e2d\u6587 になったのはなぜですか?
「エスケープ」機能が非 ASCII 文字を Unicode エスケープシーケンスに変えるからです。これは意図的な動作で、文字化けではありません。
\u4e2d は文字 中(U+4E2D)のコードポイントです。二つの形は JSON で意味的に同一で、同じ文字列にパースされます。
{
"escaped": "\u4e2d\u6587",
"plain": "中文"
}
いつエスケープが必要か。ASCII しか受け付けない古いシステムに JSON を埋め込むとき、HTTP ヘッダーに書くとき、別の文字列の中にネストするときです。 いつ不要か。ほとんどの API 転送とファイル保存には不要で、日本語を UTF-8 で直接保存すればバイトを節約できます。日本語 1 文字は 3 バイト、 エスケープすると 6 バイトです。
日本語が \u4e2d になったら、まずエンコーディングが壊れたと疑うのではなく、「エスケープ」ボタンを押したか確認してください。
2. ファイルとサイズ
どのくらいのファイルサイズに対応していますか?
ブラウザ側に厳格な制限はなく、実際の限界は三か所から来ます。
| 段階 | おおよそのボトルネック | 症状 |
|---|---|---|
| テキストボックスへの貼り付け | 1〜5 MB | 貼り付け後に入力が遅れ、カーソルが遅延 |
JSON.parse |
50〜100 MB | メインスレッドが数秒ブロックし、ページが応答しない |
| ツリー描画 | 1 万〜2 万ノード | 展開中のフレーム落ち、スクロールの固まり |
つまり数十 MB のファイルは「パースできる」が「使えない」のです。そのようなデータを本当に処理する必要があるとき、正しい手はより強いオンラインツールを探すことではなく、 ストリーミングに切り替えることです(性能とセキュリティ FAQを参照)。
経験則:2 MB 未満ならオンラインツールは滑らか、2〜10 MB は遅延を一、二回受け入れる、10 MB を超えたらローカルスクリプトを優先します。
貼り付けたらブラウザが固まりました。どうすれば?
まず更新しないでください。更新すると内容が失われ、また貼り直す必要があります。この順で救出します。
- 10〜30 秒待つ。ほとんどの場合メインスレッドはパースか描画中で、自然に回復します。
- 回復したらすぐに「圧縮」ビューに切り替えるか、ツリーを畳んで DOM ノードを減らします。
- 内容をローカルファイルにコピーし、コマンドラインに切り替えます。
# 最初の 100 行の構造だけを見て、すべてを読み込まないようにする
head -c 200000 data.json | jq . | head -n 100
# ストリーミングツールで件数を数え、メモリに読み込まない
jq -c '.items[]' data.json | wc -l
次に大きなファイルに当たったら、まず wc -c でバイト数を確認し、ブラウザに貼るか決めてください。
貼り付けたのに整形が変わらないのはなぜですか?
よくある三つの原因を頻度順に。
- 入力がすでに圧縮され、構文エラーがない:整形はインデントだけを調整するので、元が本当に二行なら 後も二行です。文字列内の改行は展開されません。
- 内容が JSON でない:たとえば JavaScript のオブジェクトリテラル(引用符なしキー、単一引用符)を貼り、 パーサーが整形ではなくエラーを報告しています。
- 間違ったボタンを押した:圧縮と整形は逆方向で、圧縮はすべてのインデントを削ります。
見分け方:出力エリア右上の文字数を見ます。整形後は増えるはずです(余分なインデントと改行)。 減っていたら圧縮を実行しています。
3. 入力と出力
結果をファイルにエクスポートするには?
三つを信頼性順に。
| 方法 | 操作 | 使うとき |
|---|---|---|
| ダウンロードボタン | 「ダウンロード」をクリックして .json ファイルを生成 |
アーカイブが必要な大きな結果 |
| クリップボードへコピー | 「コピー」をクリック | コードにそのまま戻す小さな結果 |
| 手動で全選択コピー | 出力エリアを選択して Ctrl/Cmd + C |
コピーボタンが失敗したときのフォールバック |
ダウンロードされるファイルは既定で BOM なしの UTF-8 です。これは重要です。BOM 付き JSON は多くのパーサーで即座に壊れます (構文と形式 FAQの BOM の節を参照)。
JSON5 と JSONC に対応していますか?
はい。ただし「パース」と「出力」を区別してください。
- 入力側では JSON5(単一引用符、引用符なしキー、コメント、末尾カンマ、16 進数)や JSONC(コメントのみ)を貼れます。
- 出力側では標準 JSON に変換するか、手編集を楽にするため標準 JSON を JSON5 に戻せます。
システムを越えるときは常に標準 JSON を出力します。JSON5 は人間が設定を書くための方言で、
Content-Type: application/json のリクエストボディにコメントや末尾カンマが含まれれば、通常サーバーに拒否されます。
4. 環境と互換性
スマートフォンで動きますか?
はい。インターフェースは一列に折り返し、整形、圧縮、diff、JSONPath はすべて保たれます。
ただしスマートフォンで大きなファイルを扱うのは貧弱な体験です。ソフトキーボードが内容を覆い、テキスト選択が難しく、アプリを切り替えるとブラウザがページを破棄して内容を失うことがあります。 緊急時には許容できますが、日常的にはデスクトップで行いましょう。
同じファイルが Chrome では開けるのに Safari でエラーになるのはなぜですか?
通常はブラウザ差ではなくエンコーディング差です。この順でデバッグします。
- BOM:Windows のメモ帳で保存した UTF-8 は BOM を含み、一部のパーサーが許容しません。
- 行末:CRLF と LF の混在は JSON 自体に影響しませんが、報告されるエラー行番号がずれ、「エラー位置がおかしい」ように見えます。
- 不可視文字:Web ページからコピーしたテキストはゼロ幅スペース(U+200B)を含むことがあり、目には見えないがキー照合を壊すのに十分です。
一コマンドで見透せます。
# 先頭 16 バイトの 16 進を見る。先頭の EF BB BF は BOM ありを意味する
head -c 16 data.json | xxd
5. クイックリファレンス
| 質問 | 結論 |
|---|---|
| データをアップロードするか | しない。すべてブラウザ内でローカル処理し、オフラインでも動く |
| データはどこに保存されるか | localStorage。履歴と設定だけで、ファイルは決してない |
| 妥当なファイルサイズ | 2 MB 未満は滑らか。10 MB を超えたらコマンドラインへ |
日本語が \u になった |
エスケープを押した。等価だが肥大し、通常は不要 |
| 固まったらどうする | 回復を待つ → ツリーを畳む → コピーして jq を使う |
| エクスポートは BOM なし | はい。BOM なしの UTF-8 |
| コメントに対応するか | 入力側は JSON5/JSONC。出力は標準 JSON |