실용 도구

Gzip 온라인 인코딩/디코딩

텍스트를 Gzip으로 압축해 Base64로 인코딩하고, Base64(URL-safe 자동 인식)에서 원문을 복원합니다. .gz 파일 다운로드/업로드와 실제 압축률 표시를 지원합니다. 모든 처리는 브라우저에서 로컬로 이루어지며 업로드되지 않습니다.

🔒 개인정보 안내: 압축·해제는 모두 브라우저(표준 CompressionStream API)에서 처리되며 입력과 결과는 서버로 전송되지 않고 새로고침 시 지워집니다.

사용 방법

  1. 인코딩: 텍스트를 입력하면 Gzip 데이터의 Base64 표현이 생성되어 URL·JSON·설정 파일에 바로 붙여넣을 수 있습니다.
  2. 디코딩: Base64 형식의 Gzip 데이터(표준·URL-safe 모두 자동 인식)를 붙여넣어 원문을 복원합니다.
  3. .gz 파일: ".gz 다운로드"로 입력 텍스트를 Gzip 파일로 저장하거나, ".gz 업로드"로 로컬 .gz 파일을 해제할 수 있습니다.
  4. 압축률 통계는 실제 결과를 표시합니다. 매우 짧은 텍스트나 이미 압축된 데이터(JPEG/PNG/MP4/ZIP)는 오히려 커질 수 있으며, 이는 Gzip 헤더와 알고리즘의 정상 오버헤드로 도구 오류가 아닙니다.

자주 묻는 질문

Gzip이란?

Gzip(GNU zip)은 DEFLATE 알고리즘 기반의 무손실 압축 형식(RFC 1952)으로, 헤더는 1F 8B로 고정되어 있고 CRC32 검증과 원본 길이 필드를 갖습니다. HTTP 응답 압축의 표준 형식이며 로그·JSON 등 텍스트 데이터 전송과 보관에 널리 쓰입니다.

짧은 텍스트가 압축 후 커지는 이유는?

Gzip 파일은 고정 헤더(마직 넘버·플래그·타임스탬프 등 약 10바이트)와 트레일러(CRC32 4바이트 + 원본 길이 4바이트)를 가지며, 반복이 없는 내용은 DEFLATE로도 거의 줄일 수 없습니다. 18바이트 "测试abc123你好"는 39바이트가 됩니다. 형식 오버헤드일 뿐 오류가 아닙니다.

URL-safe Base64와 표준 Base64의 차이는?

표준 Base64는 + 와 / 를 사용하므로 URL이나 파일명에서는 추가 인코딩이 필요합니다. URL-safe 버전은 이를 - 와 _ 로 대체하고 보통 끝의 = 를 생략합니다. 이 도구는 디코딩 시 두 형식을 자동 인식·정규화하고, 출력 시 체크박스로 URL-safe를 선택할 수 있습니다.

"1F 8B 헤더 없음" 오류의 의미는?

올바른 Gzip 데이터의 첫 두 바이트는 항상 0x1F 0x8B입니다. Base64는 디코딩되지만 시작 바이트가 다르면 Gzip이 아닙니다(일반 Base64 텍스트, 다른 압축 형식, 잘림/변조 가능성). 출처가 Gzip Base64인지 확인하세요.

데이터가 서버로 업로드되나요?

아니요. 이 도구는 표준 CompressionStream/DecompressionStream API를 사용해 전부 로컬에서 계산합니다. 입력 텍스트·Base64 결과·업로드한 .gz 파일은 기기를 벗어나지 않으며 새로고침 시 지워집니다.

도구마다 Base64 결과가 다른데 버그인가요?

아니요. Gzip 헤더에는 타임스탬프(MTIME), XFL/OS 등 메타데이터가 있어 구현마다 값이 다르므로 같은 텍스트라도 Gzip 바이트(그리고 Base64)가 달라질 수 있습니다. 단, 해제 결과는 항상 동일합니다. 올바름의 기준은 "복원이 원문과 일치"이지 바이트 일치가 아닙니다.

Gzip·Deflate·Brotli의 차이는?

Deflate는 압축 알고리즘 자체이고, Gzip은 DEFLATE + CRC32 검증 컨테이너(RFC 1952)로 HTTP 압축과 .gz 파일의 표준입니다. Brotli는 더 최신 알고리즘으로 압축률이 대체로 높지만 브라우저·도구 지원이 다릅니다. HTTP Content-Encoding에서는 각각 gzip / deflate / br에 대응합니다.