MIME 타입 조회
브라우저 완결 MIME 타입 조회 도구. 확장자와 Content-Type 양방향 검색, 매직 바이트로 파일 타입 감지까지 클라이언트 사이드에서 처리. 업로드 없음.
- 브라우저에서 처리
- 데이터가 브라우저 밖으로 나가지 않습니다
- 무료 · 회원가입 불필요
WeChat으로 스캔하여 공유
예시·자세한 설명·자주 묻는 질문 실제 출력이 있는 예시, 다른 도구와의 차이, 자주 묻는 질문.
MIME 타입이란
MIME 타입(공식 명칭 「미디어 타입」)은 바이트 시퀀스를 어떻게 해석할지 소프트웨어에 알려 주는 슬래시로 구분된 식별자입니다.
최상위 타입은 굵은 가족 분류(image, audio, video, text, application, multipart, message, model, font)를, 하위 타입은 구체적인 포맷
(image/png, application/pdf, text/csv)을 나타냅니다. 전체 문법은 RFC 6838에 정의되어 IANA에 등록됩니다.
웹 서버는 Content-Type 헤더로 전송하고, 브라우저는 렌더러 선택에 사용하며, API는 요청 본문 협상에 활용합니다.
매직 바이트 감지의 원리
모든 바이너리 포맷은 고유한 「지문」으로 시작합니다. 파서는 이를 통해 파일이 자칭과 일치하는지 확인합니다. PNG는
89 50 4E 47 0D 0A 1A 0A, JPEG는 FF D8 FF, PDF는 %PDF, ZIP은 50 4B 03 04입니다.
도구는 File.slice()로 앞 64바이트를 잘라 FileReader에 넘기고, 37개의 시그니처를 순회하며 첫 일치를 반환합니다.
오프셋 0이 아닌 시그니처도 있습니다. MP4는 바이트 4의 ftyp, tar는 바이트 257의 ustar 매직을 확인합니다.
업로드 검증에 중요한 이유
확장자나 브라우저 자체 신고 MIME만 믿는 것은 전형적인 업로드 취약점의 원인입니다. 사용자가 shell.php를 image.png로
이름만 바꾸면 브라우저는 즐겁게 image/png라고 보고합니다. 서버 측 바이트 수준 검증이 유일하게 신뢰할 수 있는 방어선이며,
본 도구는 서버 코드를 작성하기 전에 같은 검증을 로컬에서 미리 시뮬레이션할 수 있도록 만들었습니다. 「Detected MIME」, 「Likely extensions」,
「Browser File.type」 세 열을 비교하면 어떤 입력이 허술한 검증 로직을 빠져나갈지 몇 초 안에 드러납니다.
컨테이너 포맷과 ZIP 문제
현대의 오피스 포맷 대부분은 옛 포맷 위에 만들어진 컨테이너입니다. .docx는 XML의 ZIP 아카이브, .xlsx,
.pptx, .epub, .apk, .jar는 모두 동일한 ZIP 매직 바이트를 공유합니다.
도구가 application/zip을 보고할 때 이 상황을 명시합니다. 내부 포맷을 더 확인하려면 ZIP 중앙 디렉터리 항목 이름을 읽어야 합니다.
「Detected MIME」은 바이트 레벨에서 항상 정확하고, 애플리케이션 레벨 타입은 한 단계 더 필요할 뿐입니다.
주요 활용
- S3 / Cloudflare R2 업로드에 올바른
Content-Type을 설정해 브라우저가 파일을 다운로드 대신 렌더링하도록. - 서드파티 API 호출 시 정확한
Accept값 선택. - CDN이
.webp를 잘못된 타입으로 서빙해 AVIF 협상을 무너뜨리는 문제 진단. - 파일이 페이지를 떠나기 전에 저렴한 사전 검증으로 활용하여 서버 검증 전에 거친 입력을 걸러내기.
- 서버가 Content-Disposition을 잊었을 때 다운로드된 바이너리 blob의 실체 확인.
의도된 경계
이 도구는 조회 테이블과 매직 바이트 감지기입니다. 바이러스 스캐너도, 권한 게이트도, 컨테이너 포맷의 내부 구조 파서도 아닙니다.
고정 헤더가 없는 순수 텍스트(CSV, JSON, 일반 텍스트, 소스 코드)는 어떤 바이너리 시그니처에도 일치하지 않을 때 브라우저의
File.type으로 대체됩니다. 그 이상으로 깊이 들어가는 텍스트 내용 감지가 필요하다면, 도메인에 맞춰 조율한 서버 라이브러리를 사용하세요.
FAQ
MIME 데이터베이스는 어디서 왔나요?
웹에서 자주 쓰는 타입을 RFC 6838 최상위 타입별로 묶은 선별 목록입니다. 155개 중 106개는 IANA Media Types 레지스트리(2026-09-24)에 등록되어 있고, 49개는 video/webm, image/x-icon 같은 미등록 관용 타입입니다. 빌드 시 페이지에 정적으로 포함되어 조회할 때 외부 API를 호출하지 않습니다. application / image / audio / video / text / font / multipart / message / model 아홉 개 최상위 타입을 다루며 example과 haptics는 포함하지 않습니다.
파일 감지가 업로드를 하나요?
아니요. 감지는 브라우저 File API로 드롭한 파일의 앞 64바이트만 읽습니다. 바이트는 어디로도 전송되지 않으며, 전체 식별 파이프라인은 사용자 기기에서 실행되는 JavaScript입니다. 네트워크를 끊어도 동작합니다.
감지 결과가 확장자와 다른 이유는?
현대의 많은 포맷은 컨테이너입니다. docx, xlsx, pptx, EPUB, JAR은 바이트 수준에서 ZIP 아카이브이므로 magic bytes는 application/zip을 보고합니다. 도구는 「바이트 기반 타입」과 「확장자가 주장하는 타입」을 함께 보여 주어, 서버 측 검증 로직에서 클라이언트의 자체 신고를 신뢰하지 않도록 도와줍니다.
고정 헤더가 없는 포맷은요?
CSV, JSON, SQL, 소스 코드 같은 순수 텍스트 포맷에는 신뢰할 만한 이진 헤더가 없습니다. 어떤 시그니처와도 일치하지 않을 때는 브라우저의 File.type(운영체제가 확장자에서 추정한 값)으로 대체하고 「대체임」을 명시하므로 magic bytes 결론과 혼동되지 않습니다.
검색 패널을 Content-Type 헤더 레퍼런스로 쓸 수 있나요?
예. 각 결과 옆의 MIME 문자열이 HTTP Content-Type / Accept / Content-Disposition 헤더, S3 메타데이터, fetch() 옵션 등에 그대로 넣을 값입니다. 확장자 열은 참고 정보이며 헤더 값 자체는 아닙니다.