개발자 도구
더미 파일 생성기
이미지·음성·동영상·PDF·텍스트 등 지정한 바이트 수 그대로의 더미 파일을 브라우저에서만 생성합니다. 업로드 폼의 크기 제한 테스트에 유용하며, 파일 내용은 서버로 전송되지 않습니다.
형식
| 형식 | 확장자 | MIME 타입 | 사양상 상한 | 비고 |
|---|---|---|---|---|
| 텍스트 (TXT) | .txt |
text/plain |
사실상 무제한 | 읽을 수 있는 반복 텍스트로 채웁니다 |
| CSV | .csv |
text/csv |
사실상 무제한 | 헤더가 있는 더미 표 데이터 |
| JSON | .json |
application/json |
사실상 무제한 | 하나의 문자열 필드에 채웁니다 |
| 바이너리 (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 타입·파일 크기 세 가지를 별도로 검사합니다. 이 도구는 그 외 모든 부분을 사양에 맞게 생성하므로, 크기 제한만 따로 테스트할 수 있습니다.
- "10MB까지"라는 제한은 구현에 따라 10,000,000바이트(106)일 수도, 10,485,760바이트(220)일 수도 있습니다. 단위 선택란에서 두 기준을 모두 선택할 수 있어, 경계값 정확히 그리고 1바이트 초과 두 경우 모두 테스트할 수 있습니다.
- Chrome과 Edge는 저장할 드라이브에 직접 스트리밍으로 기록하므로, 수십 GB 규모의 파일도 메모리 부담 없이 생성할 수 있습니다. Firefox와 Safari는 일단 메모리에서 조립하는 방식이라 크기에 실용적인 상한이 있습니다.
- 지원 브라우저에서는 동영상(MP4/WebM)이 브라우저 내장 인코더로 실제 몇 초 분량의 애니메이션을 녹화하므로, 열어 보면 실제로 재생됩니다. 그 외 부분(파일 대부분을 차지하는 패딩)과 다른 이미지·음성 형식의 내용물은 더미입니다. 어디까지나 크기·확장자·MIME 타입 검증이 목적입니다.
자주 묻는 질문
아니요. 생성 처리는 모두 브라우저 내부에서 완결되며, 내용이 서버로 전송되는 일은 전혀 없습니다.
네, 지원 브라우저(Chrome 등)에서는 브라우저 내장 인코더로 실제 몇 초 분량의 애니메이션을 녹화하므로 열어 보면 재생됩니다. 파일 대부분은 정확한 크기를 맞추기 위한 패딩입니다. MP4는 녹화를 지원하지 않는 브라우저에서 자동으로 "구조만 유효한 플레이스홀더"로 전환되므로 생성 자체가 실패하지 않습니다. WebM은 녹화를 지원하는 브라우저에서만 선택할 수 있습니다.
두 형식 모두 파일 크기를 기록하는 필드가 사양상 32비트(최대 약 4.29GB)로 고정되어 있기 때문입니다. 저희 구현의 제약이 아니라 포맷 사양 자체의 상한입니다.
TXT·CSV·JSON·BIN·PNG·PDF·MP4·WebM은 포맷 사양상 상한이 없으므로, 디스크에 직접 쓰기를 지원하는 최신 버전의 Chrome이나 Edge를 사용하면 매우 큰 크기까지 생성할 수 있습니다.
여담 ― "유효한 파일"과 "손상된 파일"의 경계선
대부분의 파일 형식에는 파서가 "건너뛰어도 된다"고 정의한 영역이 있습니다. PNG의 알 수 없는 청크, MP4의 free 박스, WebM의 Void 요소 등이 그 예입니다. 이들은 원래 "향후 확장을 위해 예약된, 지금의 파서는 무시해야 할 자리"로 설계되어 있어, 임의의 데이터로 채워도 파일이 손상되지 않습니다.
동영상의 경우, 패딩 앞에 "실제 영상"을 배치해 실제로 재생할 수 있도록 하고 있습니다. 영상 코덱의 비트 단위 인코딩을 직접 작성하는 것은 정확성을 보장하기 어렵기 때문에, 대신 브라우저 자체의 내장 인코더(MediaRecorder API)로 몇 초 분량의 애니메이션을 녹화하게 하고 그 뒤에 패딩을 추가하는 방식을 택했습니다. "항상 확실히 유효한 파일을 반환한다"는 방침과 "실제로 보이는 동영상을 원한다"는 요구를 양립시키기 위한 방법입니다.
흥미롭게도 ZIP 파일은 끝부분의 "중앙 디렉터리"만 읽으면 전체 내용 목록을 알 수 있도록 설계되어 있습니다. 이는 자기 테이프 시절 끝에서부터 읽어 나가던 운용 방식의 흔적이라고도 하며, 지금도 거대한 ZIP에서 특정 파일 하나만 빠르게 꺼낼 수 있는 이유가 됩니다.