Tums.io
How It Works

파일은 내 기기를
떠나지 않습니다

Tums.io의 모든 변환과 편집은 서버가 아닌 내 브라우저 안에서 처리됩니다.

브라우저가 곧 변환 엔진입니다

일반적인 온라인 변환 도구는 파일을 서버로 보내서 처리한 뒤 결과를 돌려받습니다. Tums.io는 다릅니다. 파일이 네트워크를 타지 않고, 내 기기의 브라우저가 변환을 직접 수행합니다.

파일 선택

파일이 브라우저 메모리에 올라갑니다. 이 시점에서 파일은 외부로 나가지 않습니다.

디코딩

브라우저가 원본 포맷을 읽어 픽셀 데이터로 변환합니다.

처리·인코딩

픽셀 데이터를 목표 포맷으로 다시 인코딩합니다. CPU는 내 기기의 것입니다.

다운로드

변환된 파일이 내 기기로 저장됩니다. 서버에는 아무것도 남지 않습니다.

모든 과정이 브라우저 안에서만 완결됩니다. 파일은 네트워크를 통해 어디에도 전송되지 않습니다.

포맷마다 다른 변환 방식

이미지 파일 포맷은 저마다 다른 방식으로 픽셀을 저장합니다. Tums.io는 각 포맷의 특성에 맞는 디코더를 브라우저 안에서 실행해 정확하게 변환합니다.

HEIC / HEIF libheif

애플이 iOS 11부터 도입한 포맷입니다. HEVC(H.265) 영상 압축 기술을 이미지에 응용해 JPG 대비 절반 용량에 동일한 화질을 구현합니다.

Windows나 Android에서 열리지 않는 이유는 이 포맷을 해석하는 디코더가 기본 설치되어 있지 않기 때문입니다. Tums.io는 libheif 라이브러리를 WebAssembly로 컴파일해 브라우저 안에서 직접 실행합니다.

  • HEIC 파일에서 HEVC 비트스트림 추출
  • libheif가 픽셀(RGBA) 데이터로 디코딩
  • Canvas API로 JPG 인코딩 후 다운로드
WEBP Canvas API

구글이 개발한 웹 최적화 포맷입니다. JPG보다 25~35% 더 작은 용량으로 동일한 품질을 제공하며, 투명도(알파 채널)도 지원합니다.

크롬과 같은 최신 브라우저는 WEBP를 기본 지원하므로, 브라우저가 직접 파일을 읽어 Canvas에 그린 뒤 JPG로 재인코딩합니다. 투명 영역은 흰색 배경으로 채워집니다.

  • 브라우저 내장 WEBP 디코더로 이미지 로드
  • Canvas에 렌더링 (투명→흰색 처리)
  • toBlob() API로 JPG 인코딩
PDF PDF.js

PDF는 이미지가 아닌 문서 포맷입니다. 텍스트, 벡터 그래픽, 이미지, 폰트 정보가 섞여 있어 단순한 이미지 디코더로는 읽을 수 없습니다.

Mozilla가 만든 PDF.js 라이브러리가 PDF를 페이지 단위로 렌더링해 Canvas에 그립니다. 렌더링 해상도(DPI)를 높일수록 더 선명한 JPG를 얻을 수 있습니다.

  • PDF.js로 각 페이지를 벡터 렌더링
  • 설정한 DPI 배율로 Canvas에 래스터화
  • 페이지별 JPG 생성 후 ZIP으로 묶기
GIF Canvas API

GIF는 최대 256색만 저장할 수 있는 오래된 포맷입니다. 애니메이션은 여러 프레임을 하나의 파일 안에 순서대로 쌓아서 구현합니다.

브라우저가 GIF를 디코딩한 뒤 각 프레임을 Canvas에 그려 PNG 또는 JPG로 추출합니다. 프레임 분할 도구는 이 과정을 모든 프레임에 반복해 ZIP으로 제공합니다.

  • GIF 바이너리에서 프레임 데이터 파싱
  • 각 프레임을 Canvas에 순차 렌더링
  • 프레임별 이미지 추출 후 ZIP 패키징

이미지는 결국 숫자의 집합입니다

어떤 포맷이든 변환의 본질은 같습니다. 원본을 픽셀 데이터로 풀고, 새 포맷의 규칙으로 다시 묶는 것입니다.

이미지 파일은 화면에 보이는 각 점(픽셀)의 색상 정보를 저장한 데이터입니다. 컬러 이미지의 픽셀 하나는 빨강(R), 초록(G), 파랑(B) 세 가지 채널의 값으로 구성되며, 투명도(Alpha)가 있으면 네 개의 숫자가 됩니다. 각 채널의 값은 0~255 사이의 정수입니다.

1,000 × 1,000 픽셀 이미지라면 픽셀이 100만 개이고, RGBA 기준으로 약 4MB의 원시(raw) 데이터가 생깁니다. 실제 파일이 그보다 훨씬 작은 이유는 압축 알고리즘 덕분입니다.

Tums.io는 Canvas API의 getImageData()를 통해 이 픽셀 배열에 직접 접근하고, toBlob()으로 원하는 포맷과 품질로 다시 인코딩합니다. 모든 연산이 JavaScript와 WebAssembly로 내 기기에서 실행됩니다.

픽셀 1개의 구성 (RGBA)
R (빨강)
184
G (초록)
107
B (파랑)
140
A (투명)
255
파일 크기 비교 (1000×1000px 기준)
원시
4 MB
PNG
~2 MB
JPG 90%
~700 KB
HEIC
~400 KB

품질 수치가 의미하는 것

JPG 변환 시 설정하는 품질(0~100%)은 손실 압축의 강도를 결정합니다. 높을수록 원본에 가깝고, 낮을수록 파일이 작아집니다.

95–100% 원본과 거의 구별 불가. 인쇄·고화질 보존용 고용량
60–79% 약간의 열화가 있으나 일반 사용에 충분. 용량 우선 시 균형
~59% 블록 노이즈가 보이기 시작. 썸네일·미리보기용 소용량

JPG는 DCT(이산 코사인 변환) 알고리즘으로 이미지를 8×8 블록 단위로 쪼개 압축합니다. 품질을 낮추면 블록 안의 세밀한 색상 변화를 생략해 용량을 줄이고, 높이면 더 많은 정보를 보존합니다.

PNG는 무손실 압축을 사용해 픽셀 데이터를 그대로 저장합니다. 품질 설정이 없는 대신 같은 해상도라면 JPG보다 항상 용량이 큽니다. 투명 배경이 필요하거나 화질 손실이 절대 허용되지 않는 경우에 적합합니다.

Tums.io의 기본 품질값은 92%로 설정되어 있습니다. 대부분의 상황에서 화질과 용량의 균형이 가장 좋은 지점입니다.

왜 서버리스 방식이 더 안전한가요

파일을 서버로 보내지 않는 것은 단순한 설계 선택이 아닙니다. 개인정보와 민감한 파일을 보호하는 가장 확실한 방법입니다.

네트워크 전송 없음

파일이 인터넷을 통해 어디에도 전송되지 않습니다. 전송 도중 탈취되거나 중간에서 가로채질 위험이 원천 차단됩니다.

서버 저장 없음

변환 결과물은 서버 어디에도 저장되지 않습니다. 브라우저 탭을 닫으면 변환 과정의 모든 데이터가 메모리에서 사라집니다.

파일 내용 비공개

Tums.io 서버는 파일의 존재 자체를 모릅니다. 어떤 파일을 변환했는지 로그가 남지 않습니다.

사용된 기술

각 도구가 어떤 기술로 동작하는지 정리했습니다.

도구 동작 방식 핵심 기술 바로가기
HEIC → JPG libheif 라이브러리를 WebAssembly로 실행해 HEVC 비트스트림을 픽셀로 디코딩 후 JPG 인코딩 WebAssemblylibheifCanvas API 사용하기 →
WEBP → JPG 브라우저 내장 WEBP 디코더로 이미지 로드 후 Canvas를 통해 JPG 재인코딩 Canvas APIBlob API 사용하기 →
PNG → JPG PNG를 Canvas에 로드해 투명 영역을 흰색으로 합성 후 JPG 인코딩 Canvas APIAlpha Compositing 사용하기 →
BMP → JPG 비압축 BMP를 브라우저가 직접 읽어 Canvas 경유 JPG 변환 Canvas APIFile API 사용하기 →
TIFF → JPG TIFF 디코딩 라이브러리로 픽셀 추출 후 JPG 인코딩 TIFF.jsCanvas API 사용하기 →
GIF → JPG GIF 바이너리를 파싱해 프레임별로 Canvas에 렌더링 후 개별 이미지 추출 Canvas APIGIF ParserJSZip 사용하기 →
PDF → JPG PDF.js가 각 페이지를 벡터 렌더링해 Canvas에 래스터화 후 JPG 추출 PDF.jsCanvas APIJSZip 사용하기 →
이미지 잘라내기 Canvas에 이미지를 로드하고 선택 영역의 픽셀만 새 Canvas에 복사해 인코딩 Canvas APIdrawImage() 사용하기 →

직접 확인해 보세요

설명보다 한 번 써보는 게 빠릅니다.

도구 목록 보기 →