PDF 문서의 모든 페이지를 이미지 파일로 하나씩 뽑아내는 도구입니다. Mozilla의 PDF.js 렌더러가 각 페이지를 지정한 해상도로 HTML 캔버스에 그린 뒤, 그 결과를 JPG·PNG·WebP로 인코딩합니다. JPEG 인코딩에는 브라우저가 지원하는 경우 MozJPEG의 WebAssembly 빌드를 사용하는데, 같은 화질에서 브라우저 기본 인코더보다 눈에 띄게 작은 파일을 만듭니다. 지원되지 않으면 기본 인코더로 자동 전환됩니다.
이 과정은 전부 사용자 기기 안에서 일어납니다. 업로드 단계도, 대기열도, 남의 서버 디스크에 남는 임시 사본도 없습니다. 대신 변환 속도는 서버 부하나 인터넷 속도가 아니라 기기 성능에 좌우됩니다.
PDF는 디스크에서 브라우저 메모리로 바로 읽힙니다. 전송되는 데이터가 없으므로 계약서, 진료 기록, 신분증 사본도 기기 밖으로 나가지 않고 변환할 수 있습니다.
PDF 페이지에는 고유한 픽셀 크기가 없습니다. 1/72인치를 1포인트로 하는 좌표계로만 기술되어 있죠. 화질 설정은 이 페이지 형상에 곱하는 렌더링 배율이고, 결과 DPI는 거기서 그대로 결정됩니다.
| 설정 | 렌더링 배율 | 실효 DPI | JPEG 품질 | A4 출력 크기 |
|---|---|---|---|---|
| 높음 | 2.0배 | 약 144 DPI | 0.92 | 약 1190 × 1684 px |
| 보통 | 1.5배 | 약 108 DPI | 0.85 | 약 892 × 1263 px |
화면에서 읽거나 확대하거나 나중에 OCR을 돌릴 문서라면 높음이 기본값으로 적절합니다. 긴 문서를 변환하는데 알아볼 수 있는 썸네일이나 메일 첨부용이면 보통이 낫습니다. 어느 쪽이든 페이지의 긴 변은 8192 px로 제한됩니다. 브라우저가 안정적으로 다루는 캔버스 최대 크기가 그 정도라서, 포스터나 도면처럼 유난히 큰 페이지는 이 한계에 맞춰 축소됩니다.
JPG는 스캔 문서, 사진, 널리 공유할 파일에 무난한 선택입니다. 열지 못하는 프로그램이 없습니다. PNG는 무손실이라 글자 가장자리와 얇은 표 선이 완벽하게 유지되지만, 글자가 많은 페이지는 같은 페이지의 JPG보다 5~10배까지 커질 수 있습니다. WebP는 그 중간으로, 이미지를 웹페이지에 쓸 때 가장 좋습니다. PNG에 가까운 선명함을 JPG 정도의 용량으로 담습니다. 최신 브라우저는 모두 지원하지만, 오래된 데스크톱 뷰어 중에는 아직 열지 못하는 것도 있습니다.
아니요. 변환은 PDF.js와 HTML 캔버스 API로 브라우저 안에서 실행됩니다. 파일은 페이지가 디스크에서 메모리로 직접 읽어들이며 기기 밖으로 나가지 않으므로, 나중에 삭제할 사본도 없고 업로드를 기다릴 필요도 없습니다.
높음은 페이지 원본 크기의 2배, 약 144 DPI로 렌더링하고 JPEG 품질 0.92로 인코딩합니다. 보통은 1.5배, 약 108 DPI에 품질 0.85입니다. 따라서 A4 한 장은 높음에서 약 1190 × 1684 픽셀, 보통에서 약 892 × 1263 픽셀이 됩니다.
모든 페이지가 자동으로 변환됩니다. 페이지가 둘 이상이면 원본 파일명을 딴 ZIP 하나로 묶이고, 각 이미지에는 페이지 순서대로 번호가 붙습니다. report-1.jpg, report-2.jpg 같은 식입니다. 한 페이지짜리는 JPG 한 장으로 바로 받습니다.
스캔 문서, 사진, 일반적인 공유용이면 JPG입니다. 글자·표·선 위주 페이지에서 가장자리를 무손실로 유지하고 싶다면 PNG를 쓰되 파일이 훨씬 커진다는 점을 감수해야 합니다. 웹사이트에 올릴 이미지이고 PNG급 화질을 JPG 정도 용량으로 원한다면 WebP가 맞습니다.
서버가 개입하지 않으므로 서버 측 제한은 없습니다. 실질적인 한계는 기기의 가용 메모리입니다. 각 페이지를 캔버스에 렌더링한 뒤 인코딩하기 때문입니다. 또 페이지의 긴 변은 8192픽셀로 제한되는데, 이는 브라우저가 안정적으로 지원하는 캔버스 최대 크기입니다.
페이지를 처음 열 때 PDF.js와 JSZip 라이브러리를 받아와야 하므로 인터넷 연결이 필요합니다. 다만 일단 로드된 뒤의 변환 과정은 네트워크 요청을 전혀 하지 않으므로, 변환 도중 연결이 끊겨도 중단되지 않습니다.
