PDF 압축은 파일의 각 페이지를 브라우저에서 비트맵으로 렌더링하고, 고른 선명도로 JPEG로 다시 인코딩한 뒤, 그 JPEG들을 페이지 크기가 그대로인 새 PDF로 다시 조립합니다. 파일은 업로드되지 않고, 결과는 보통 원본의 몇 분의 1에서 수십 분의 1로 줄어듭니다.

가장 잘 맞는 대상은 스캔본과 이미지 위주 파일입니다. 휴대폰 스캔 앱이 만든 PDF, 복사기에서 바로 나온 계약서, 카메라로 찍은 영수증 같은 파일은 원래 페이지마다 큰 이미지 하나라서, 합리적인 해상도와 품질로 다시 인코딩하면 용량이 흔히 70% 이상 줄고 화면에서는 차이를 거의 느끼지 못합니다.

맞지 않는 대상은 글자가 중심이고 원래 용량이 크지 않은 파일입니다. 페이지를 통째로 이미지화하면 원래 몇 KB였던 벡터 글자가 100–200 KB짜리 이미지가 되어, 파일이 작아지기는커녕 "선택·검색·복사 가능"이라는 성질을 잃습니다. 도구 패널의 노란 안내가 바로 이 이야기이고, 이 글의 동작 원리에서 이유를 설명합니다.

세 프리셋은 세 조합의 고정 매개변수에 대응합니다. 화면(72 DPI, JPEG 품질 0.55), 균형(110 DPI, 0.70, 기본값), 인쇄(150 DPI, 0.82). 압축 전에 파일이 어디로 갈지 먼저 정하세요. WeChat으로 보낼 거면 화면, 보관하면서 인쇄도 고려하면 균형이나 인쇄를 고르는 편이 나중에 여러 번 시도하는 것보다 시간을 아낍니다.

1. 01PDF 추가끌어다 놓거나 클릭해 선택합니다. 왼쪽 목록에 페이지 수와 원본 용량이 표시됩니다. 암호화 파일은 먼저 "PDF 잠금 해제"로 비밀번호를 제거하세요.
2. 02선택 사항: 페이지 정리가운데 영역에서 빈 페이지, 거꾸로 된 페이지를 지웁니다. 압축은 정리한 배열대로 출력하고, 지운 페이지는 용량을 차지하지 않습니다.
3. 03"압축" 패널로 전환해 프리셋 선택패널 아래 작은 글씨가 현재 프리셋의 DPI와 용도를 설명합니다. "원본 용량"도 여기 표시되어 비교하기 편합니다.
4. 04"압축 시작" 클릭아래 진행 막대가 페이지 단위로 올라갑니다. 페이지마다 렌더링한 뒤 인코딩하므로 페이지가 많으면 몇 초에서 수십 초 기다려야 합니다.
5. 05결과 확인파일 이름에 절감 비율이 붙습니다. 예: scan_압축_87%절감.pdf. 출력이 원본보다 크면 이름에 "절감"이 들어가지 않는데, 이 파일은 이미지화 압축에 맞지 않는다는 신호입니다. 결과 카드에서 "다시 내려받기"나 "작업 공간에 추가해 계속 처리"를 할 수 있습니다.

6쪽 스캔본으로, 각 페이지가 2480×3508 픽셀(A4 300 DPI 상당) JPEG이고 원본이 2.41 MB인 경우. 세 프리셋의 실제 결과:

프리셋   렌더링 해상도          페이지당 픽셀   페이지당 JPEG   6쪽 합계     절감
화면    72 DPI  · 품질 0.55   595×841       ≈ 20 KB      120 KB       95%
균형    110 DPI · 품질 0.70   909×1286      ≈ 51 KB      302 KB       87%
인쇄    150 DPI · 품질 0.82   1240×1753     ≈ 109 KB     642 KB       73%

대조로, 벡터 글자만 있는 12쪽 계약서(11.7 KB)를 균형 프리셋으로 압축하면 1.65 MB가 됩니다. 페이지마다 약 137 KB짜리 이미지가 되고 글자도 더는 선택할 수 없습니다.

여기서 말하는 "압축"이란

PDF 자체가 이미 압축 형식입니다. 글자는 폰트 윤곽선으로 표현하고, 이미지 내부는 대개 JPEG나 Flate로 압축되어 있습니다. 이른바 "PDF 압축"은 도구마다 완전히 다른 세 가지를 뜻할 수 있습니다.

1. 무손실 재정리: 참조되지 않는 객체를 없애고 중복 리소스를 합치고 객체 스트림을 켭니다. 용량 변화는 보통 몇 퍼센트입니다.
2. 구조를 보존하는 손실 처리: 파일 안의 이미지 객체만 다운샘플링하고 다시 인코딩하며 글자와 벡터는 그대로 둡니다. 전문 조판 소프트웨어와 Ghostscript의 방식으로 효과는 좋지만 구현이 복잡합니다.
3. 전체 페이지 이미지화: 페이지마다 그림으로 렌더링한 뒤 다시 만듭니다. 구현이 단순하고 스캔본에 가장 효과가 좋지만 페이지의 모든 것이 픽셀이 됩니다.

이 도구는 3번을 씁니다. 이 점을 이해하면 어떤 파일에서 효과가 있고 어떤 파일에서 역효과가 나는지 예측할 수 있습니다.

페이지는 어떻게 픽셀이 되나

PDF의 페이지 크기는 **포인트(pt)**로 재고, 1 pt = 1/72인치이며 A4는 595.28 × 841.89 pt입니다. 렌더링할 때 도구는 pdf.js로 페이지를 캔버스에 그리는데, 축척은 DPI ÷ 72입니다.

• 72 DPI → 축척 1.0 → 595 × 841 픽셀
• 110 DPI → 축척 1.53 → 909 × 1286 픽셀
• 150 DPI → 축척 2.08 → 1240 × 1753 픽셀

이 단계가 리샘플링입니다. 원본 스캔본이 300 DPI라면 110 DPI 출력에서는 픽셀의 약 87%를 버립니다((110/300)² ≈ 0.13). 픽셀이 줄면 JPEG 인코딩 전 데이터도 줄어듭니다. 이것이 용량 감소의 첫 번째 원천이고 되돌릴 수 없습니다.

렌더링할 때 페이지의 모든 요소(글자, 벡터 도형, 이미지, 주석 모양)가 같은 비트맵에 합성되고 배경은 흰색으로 채워집니다(JPEG는 투명을 지원하지 않음).

JPEG 품질 매개변수는 무엇을 조절하나

비트맵은 이어서 브라우저의 JPEG 인코더로 인코딩되고, 품질 매개변수(0–1)는 캔버스의 toBlob() 인터페이스에서 옵니다. JPEG는 이미지를 8×8 블록으로 나눠 이산 코사인 변환을 한 뒤 양자화 테이블에 따라 고주파 세부를 버립니다. 품질이 낮을수록 양자화 간격이 커지고 남는 고주파가 줄어 파일이 작아지며, 가장자리 근처의 "링잉"과 블록 모양 열화가 뚜렷해집니다.

세 프리셋의 품질 값 0.55 / 0.70 / 0.82는 "스캔한 글자를 여전히 읽을 수 있는" 기준으로 맞춘 것입니다. 0.5 아래에서는 획 가장자리에 잡티가 뚜렷해지고, 0.85 위로는 용량이 빠르게 늘어나는 데 비해 눈으로 느끼는 이득은 작습니다. 인코딩 세부(색차 샘플링 여부, 어떤 양자화 테이블을 쓰는지)는 브라우저가 정하므로 같은 프리셋이라도 브라우저에 따라 출력 용량이 10~20% 차이 날 수 있습니다.

텍스트형 PDF는 왜 커지나

PDF에서 벡터 글자 한 페이지의 비용은 폰트 1회 임베드(수십 KB, 문서 전체 공유) + 글자마다 몇 바이트의 위치 지정 명령입니다. A4 한 페이지를 빽빽하게 채운 글자도 2–5 KB에 그칠 수 있습니다.

같은 페이지를 이미지화하면 110 DPI에서 117만 픽셀입니다. 글자 가장자리는 JPEG가 가장 서투른 고주파 콘텐츠라 품질 0.7이라도 흑백 가장자리를 그럴듯하게 인코딩하려면 100–150 KB가 필요합니다. 그래서 12쪽 계약서가 11.7 KB에서 1.65 MB로, 100배 넘게 늘어납니다. 버그가 아니라 이미지화 방식의 고유한 성질입니다. 원본의 각 페이지가 이미 그보다 큰 그림일 때만 이득이 있습니다.

재구성된 파일은 어떻게 생겼나

출력은 완전히 새 PDF입니다. 각 페이지는 원래 페이지와 시각적 크기가 같은 빈 페이지이고 그 위에 페이지를 덮는 JPEG(PDF에서는 DCTDecode 필터 이미지 객체)가 깔립니다. 원본의 폰트, 벡터, 텍스트 레이어, 북마크, 폼, 링크, 메타데이터는 새 파일에 들어가지 않습니다. 작업 공간에서 삽입한 빈 페이지는 벡터 빈 페이지로 남아 이미지화되지 않고, 스캔본에 원래 있던 빈 페이지는 다른 페이지와 똑같이 이미지로 렌더링됩니다.

새 파일이 순수 이미지라 어떤 PDF 뷰어로도 열려 호환성은 매우 좋습니다. 다만 "찾기"는 아무것도 못 찾고 화면 낭독기도 아무 글자도 읽지 못합니다.

• 페이지를 먼저 지우고 압축: 가운데 영역에서 빈 페이지와 무관한 페이지를 지우면 압축할 때 용량을 차지하지 않습니다. 양면 스캔의 빈 뒷면에 특히 효과적입니다.
• 텍스트 레이어를 남기는 대안 경로: 파일이 글자 위주인데 큰 이미지가 몇 장 끼어 있다면 이미지화는 손해입니다. "PDF 이미지 추출"로 이미지를 꺼내 "이미지 압축"으로 줄인 뒤 다시 배치하거나, 그냥 두세요. 텍스트형 PDF는 원래 크지 않은 경우가 많습니다.
• 텍스트를 먼저 추출하고 압축: 스캔본을 아주 작게 만들면서 글자 내용도 남기고 싶다면 "PDF 텍스트 추출"로 선택 가능한 텍스트를 txt로 저장한 뒤 PDF를 압축해 두 파일을 함께 보관합니다.
• 프리셋과 용도 연결: 휴대폰에서만 본다 → 화면, 일상 전자 보관 → 균형, 인쇄할 수도 있다 → 인쇄. 150 DPI는 A4 인쇄에서 본문을 읽기에 충분하지만 작은 각주는 다소 흐려집니다.
• "모아찍기"와 조합: 유인물을 먼저 화면 프리셋으로 압축하고 "PDF 모아찍기"로 한 장에 2쪽씩 배치하면 가장 작은 인쇄용 유인물이 됩니다.
• 초대형 파일 나눠 압축: 수백 쪽 스캔본을 한 번에 압축하면 메모리를 많이 씁니다. "PDF 분할"로 몇 토막 내어 각각 압축한 뒤 병합하세요.

입력 형식

PDF. 한 번에 왼쪽 목록에서 현재 선택한 파일을 처리합니다.

암호화 파일

먼저 "PDF 잠금 해제"로 비밀번호를 제거해야 합니다.

프리셋

화면(72 DPI / 품질 0.55), 균형(110 DPI / 0.70), 인쇄(150 DPI / 0.82). 매개변수는 고정이고 사용자 지정 DPI나 품질은 제공하지 않습니다.

출력

페이지마다 JPEG가 페이지를 채우는 새 PDF. 페이지 크기와 방향은 현재 배열과 같고, 작업 공간에서 삽입한 빈 페이지는 벡터로 남습니다.

텍스트

출력에서 글자는 선택·검색·복사할 수 없고 화면 낭독기도 읽지 못합니다.

효과 경계

스캔본과 사진형 PDF는 보통 70%–95% 절감됩니다. 벡터 텍스트형 PDF는 출력이 원본보다 커지고 파일 이름에 "절감"이 들어가지 않습니다.

보존하지 않음

텍스트 레이어, 폰트, 벡터 도형, 북마크, 링크, 폼, 주석의 편집 가능성, 메타데이터, 디지털 서명.

파일 용량

하드 상한은 없고 200 MB를 넘으면 느릴 수 있다고 알립니다. 페이지마다 렌더링한 비트맵이 메모리에 임시로 남아, 150 DPI의 A4 비트맵은 약 8.7 MB(비압축)이므로 페이지가 아주 많으면 휴대폰에서 메모리가 부족할 수 있습니다.

하지 않는 일

텍스트 레이어를 남기는 "이미지만 압축" 방식, 무손실 재정리, OCR은 하지 않습니다.

• "압축해도 글자가 선택돼야 한다": 안 됩니다. 페이지를 이미지화하면 글자는 픽셀일 뿐입니다. 선택 가능한 글자가 필요하면 원본을 남기거나 먼저 텍스트를 추출하세요.
• "모든 PDF는 압축하면 작아진다": 텍스트형 PDF는 커지고, 때로는 수십 배 커집니다. 파일 이름에 "절감"이 있는지 보면 이번이 이득인지 알 수 있습니다.
• "인쇄 프리셋 = 인쇄 품질": 150 DPI는 본문을 읽기에 충분하지만 인쇄에서 보통 요구하는 300 DPI에는 못 미칩니다. 고품질 인쇄가 필요하면 원본을 남기세요.
• "여러 번 압축하면 더 작아진다": 두 번째 압축은 이미 JPEG인 페이지를 다시 렌더링하고 다시 인코딩하는 것이라 용량은 거의 그대로이고 화질만 계속 손실됩니다. 프리셋을 한 번에 제대로 고르세요.
• "압축 = 최적화": 이 도구는 불필요한 객체를 없애거나 구조를 고치지 않습니다. 파일이 열리지 않으면 "PDF 복구"를 쓰세요.

압축의 모든 단계가 — pdf.js로 페이지 렌더링, 캔버스로 JPEG 인코딩, pdf-lib으로 파일 재구성 — 내 브라우저 안에서 이루어지고 파일은 어떤 서버로도 업로드되지 않습니다. 중간에 생기는 비트맵은 메모리에만 있다가 페이지를 닫으면 해제됩니다. 오프라인에서도 쓸 수 있습니다.

• ISO 32000-1:2008, PDF 1.7, §8.3.2.3 사용자 공간(기본 단위 1/72인치), §7.4.8 DCTDecode 필터(PDF에서 JPEG 이미지의 캡슐화): https://opensource.adobe.com/dcs/pdf/PDF32000_2008.pdf（访问日期：2026-09-08）
• ITU-T Recommendation T.81(1992), Digital compression and coding of continuous-tone still images(JPEG 표준, 양자화와 DCT): https://www.w3.org/Graphics/JPEG/itu-t81.pdf（访问日期：2026-09-08）
• MDN Web Docs, HTMLCanvasElement.toBlob() — quality 매개변수의 정의와 값 범위: https://developer.mozilla.org/zh-CN/docs/Web/API/HTMLCanvasElement/toBlob（访问日期：2026-09-08）
• Mozilla pdf.js, 캔버스로의 페이지 렌더링 getViewport({ scale }) 의미(scale = 1은 72 DPI): https://mozilla.github.io/pdf.js/（访问日期：2026-09-08）