開発者ツール
ダミーファイル生成
画像・音声・動画・PDF・テキストなど、指定したバイト数ちょうどのダミーファイルをブラウザだけで生成します。アップロードフォームのサイズ上限テストに便利です。ファイルは一切サーバーに送信されません。
形式
| 形式 | 拡張子 | MIME タイプ | 仕様上の上限 | 備考 |
|---|---|---|---|---|
| テキスト (TXT) | .txt |
text/plain |
実質無制限 | 読める繰り返しテキストで詰めます |
| CSV | .csv |
text/csv |
実質無制限 | ヘッダー付きのダミー表データ |
| JSON | .json |
application/json |
実質無制限 | 1つの文字列フィールドに詰めます |
| バイナリ (BIN) | .bin |
application/octet-stream |
実質無制限 | 0x00〜0xFF を繰り返す任意バイト列 |
| 画像 (PNG) | .png |
image/png |
実質無制限 | 有効な 1x1 画像 + 詰め物チャンク |
| 音声 (WAV) | .wav |
audio/wav |
4 GiB | 無音の PCM データ（実際に再生可能） |
| 動画 (MP4) | .mp4 |
video/mp4 |
実質無制限 | 対応ブラウザでは実録画、非対応時は構造のみのプレースホルダー |
| 動画 (WebM) | .webm |
video/webm |
実質無制限 | 実際に録画した数秒のアニメーション（対応ブラウザのみ） |
.pdf |
application/pdf |
実質無制限 | 白紙 1 ページの有効な PDF | |
| ZIP | .zip |
application/zip |
4 GiB | 無圧縮の単一エントリアーカイブ |
ダミーファイル生成のヒント
- アップロードフォームの検証ロジックは 拡張子・MIME タイプ・ファイルサイズ の3つを別々にチェックしていることが多いです。このツールはすべて仕様に沿った値で生成するため、サイズ制限だけを狙い撃ちしてテストできます。
- 「10MB まで」という制限は、実装によって 10,000,000 バイト（106） だったり 10,485,760 バイト（220） だったりします。単位セレクトで両方の基準を選べるので、境界値ちょうど・1バイト超えの両方をテストできます。
- Chrome や Edge では保存先のドライブに直接ストリーム書き込みするため、数十GB規模のファイルもメモリを圧迫せず生成できます。Firefox・Safari では一旦メモリ上に組み立てるため、サイズに実用的な上限があります。
- 動画（MP4/WebM）は対応ブラウザではブラウザ内蔵のエンコーダーで実際に数秒のアニメーションを録画するため、開けば本当に再生できます。それ以外の部分（ファイルの大半を占める詰め物）や、その他の画像・音声形式の中身はダミーです。あくまでサイズ・拡張子・MIME タイプの検証が目的です。
よくある質問
いいえ。生成処理はすべてブラウザ内で完結し、内容がサーバーに送信されることは一切ありません。
はい、対応ブラウザ（Chrome 等）ではブラウザ内蔵のエンコーダーで実際に数秒のアニメーションを録画しているため、開けば再生できます。ファイルの大部分は正確なサイズに合わせるための詰め物です。MP4 は録画に対応していないブラウザでは自動的に「構造のみ有効なプレースホルダー」に切り替わるため、生成自体が失敗することはありません。WebM は録画に対応したブラウザでのみ選択できます。
どちらの形式もファイルサイズを記録するフィールドが仕様上 32bit（最大約 4.29 GB）に固定されているためです。私たちの実装の制約ではなく、フォーマット仕様そのものの上限です。
TXT・CSV・JSON・BIN・PNG・PDF・MP4・WebM はフォーマット仕様上の上限がないため、Chrome や Edge の最新版（ディスクへの直接書き込みに対応）であれば非常に大きなサイズまで生成できます。
余談ですが ― 「有効なファイル」と「壊れたファイル」の境界線
ほとんどのファイル形式には、パーサーが「読み飛ばしてよい」と定めた領域があります。PNG の未知チャンク、MP4 の free ボックス、WebM の Void 要素、ZIP のコメント領域などがその例です。これらは元々「将来の拡張のために予約された、今のパーサーが無視すべき場所」として設計されており、詰め物を入れてもファイルが壊れることはありません。
動画については、詰め物の前に「本物の映像」を置くことで実際に再生可能にしています。自前で映像コーデックのビット単位のエンコードを書くのは正確さを保証しづらいため、代わりにブラウザ自身の内蔵エンコーダー（MediaRecorder API）に数秒のアニメーションを録画させ、その後ろに詰め物を追加する方式を採っています。「常に確実に有効なファイルを返す」という方針と、「本当に見える動画」という要望を両立させる工夫です。
興味深いことに、ZIP ファイルは末尾の「セントラルディレクトリ」を読むだけで中身の一覧が分かる設計になっています。これは磁気テープ時代に末尾から読み進める運用を想定した名残とも言われ、今でも大きな ZIP から特定の1ファイルだけを高速に取り出せる理由になっています。