WebP vs AVIF vs JXL: 2026년 이미지 포맷 비교

빠른 답변: 2026년 대부분의 웹사이트라면 AVIF를 우선, WebP를 폴백으로 두는 것이 정답입니다(AVIF는 같은 시각적 품질에서 JPEG보다 약 50% 작고, 2026년 브라우저 지원도 견고합니다). Apple 전용 맥락이라면 JPEG XL이 인코딩 속도와 점진적 디코딩에서 앞서지만 여전히 Safari 외에는 거의 지원되지 않습니다. 이메일, 소셜, 일반 공유에는 JPEG가 안전한 선택으로 남아 있고, 현대 포맷은 자신이 통제할 수 있는 자리에서 쓰는 것이 맞습니다. 본인의 이미지로 포맷을 비교해 보고 싶다면 이미지 변환기나 이미지 압축기에 드롭하고 파일 크기를 실시간으로 확인하세요.

JPEG는 33년이 됐습니다. WebP는 15년, AVIF는 2019년 출시, JPEG XL은 2022년에 표준화되었습니다. 2026년 시점에서 세 현대 포맷은 모두 성숙했고, 무엇을 쓸지는 더 이상 이론 문제가 아닙니다. Core Web Vitals, 페이지 로드 속도, 모바일 데이터 비용, 저장 공간에 곧장 영향을 줍니다. 이 가이드는 2026년 기준의 실용적 비교입니다. 각 포맷이 무엇인지, 파일 크기 실수치, 어디서 동작하는지, 어떻게 고르는지를 정리합니다.

후보들, 한 단락씩

WebP(Google, 2010)는 보수적인 현대 선택지입니다. 같은 품질에서 JPEG보다 약 25~35% 작고, 완전한 무손실 모드, 투명도(알파), 애니메이션을 지원합니다. 2026년 브라우저 지원은 보편적입니다(모든 현대 브라우저, Gmail, WhatsApp, 모든 CMS). 단점은 AVIF에 비해 인코딩 품질이 훌륭하다고 말하긴 어렵고, EXIF 메타데이터 지원이 들쑥날쑥하다는 것입니다.

AVIF(Alliance for Open Media, 2019)는 순수 파일 크기로는 현대의 승자입니다. AV1 비디오 코덱 기반. 같은 시각 품질에서 JPEG보다 약 50%, WebP보다 약 25~35% 작습니다. 투명도, HDR, 광색역, 12비트 픽셀을 지원합니다. 브라우저 지원은 2024년에 동등 수준에 도달했고, 2026년에는 모든 주요 브라우저가 AVIF를 네이티브로 디코딩합니다. 단점은 WebP보다 인코딩이 느리다는 점(배치 작업에서는 실질적인 문제)과, 아주 오래된 메일 클라이언트는 본문에서 AVIF를 표시하지 못한다는 점입니다.

JPEG XL(.jxl, ISO/IEC 18181, 2022)은 사진가와 엔지니어들이 기술적으로 선호하는 포맷입니다. 기존 JPEG의 무손실 트랜스코딩이 가능하고(JPEG를 JXL로 다시 인코딩하면 품질 손실 없이 약 20% 줄어듭니다), 1비트 알파, 진정한 점진적 디코딩, 뛰어난 인코딩/디코딩 속도를 갖췄습니다. iOS 17+, macOS Sonoma+의 Safari 17+에서 네이티브 지원. 단점은 Chrome이 2022년에 JXL을 빼버린 뒤 2026년 현재까지 다시 넣지 않아서, 크로스 브라우저 웹 사용은 JS 폴리필이나 폴백이 필요하다는 점입니다.

파일 크기 비교: 실수치

같은 iPhone 가로 사진(4032 × 3024 픽셀)을 "시각적으로 동일한" 품질로 각 포맷에 인코딩한 결과입니다.

포맷	파일 크기	JPEG 대비	시각 품질
JPEG(품질 92)	2.8 MB	기준	우수
JPEG(품질 85)	1.6 MB	-43%	매우 좋음
WebP(품질 80)	1.1 MB	-61%	매우 좋음
AVIF(품질 60)	0.78 MB	-72%	매우 좋음
JPEG XL(effort 7, distance 1.0)	0.92 MB	-67%	매우 좋음

투명도가 있는 600 × 800 제품 사진의 경우:

포맷	파일 크기	투명도?
PNG(무손실)	280 KB	있음
WebP(품질 90)	88 KB	있음
AVIF(품질 70)	52 KB	있음
JPEG XL(effort 7)	65 KB	있음

대부분의 사진 콘텐츠에서 패턴은 일관됩니다. AVIF가 크기에서 이기고, JXL이 근접하며, WebP는 보편적인 중도, JPEG가 가장 크지만 가장 호환됩니다. 이미지 내용(평평한 영역이냐 디테일이 많냐, 사진이냐 합성 이미지냐)에 따라 수치는 10~20% 흔들립니다.

2026년 브라우저 지원

포맷	Chrome	Edge	Safari	Firefox	iOS	Android
WebP	있음	있음	있음(14+)	있음	있음	있음
AVIF	있음	있음	있음(16.4+)	있음(113+)	있음(16.4+)	있음(Chrome 85+)
JPEG XL	없음(2022 제거)	없음	있음(17+)	부분(플래그 뒤)	있음(17+)	없음

2026년의 실무 요약:

• WebP는 사용자의 99%에서 작동, 따로 챙길 만한 예외가 사실상 없습니다.
• AVIF는 사용자의 97%에서 작동. 롱테일을 위한 JPEG 폴백을 같이 배포하세요.
• JPEG XL은 Apple 생태계 안에서만 네이티브 작동. iOS 앱과 Apple 전용 사진 워크플로에는 유용하지만, 아직 일반 웹용은 아닙니다.

인코딩 속도 비교

압축 벤치마크에서 자주 누락되는 실무 요소: 실제로 파일을 인코딩하는 데 얼마나 걸리나?

포맷	인코딩 시간(4032×3024 사진 1장, 단일 코어)
JPEG(품질 85)	0.05초
WebP(품질 80)	0.18초
JPEG XL(effort 7)	0.32초
AVIF(품질 60, speed 6)	1.4초
AVIF(품질 60, speed 9 / 빠름)	0.55초

AVIF는 기본 설정에서 JPEG보다 인코딩이 약 7~10배 느립니다. 사진 100장 배치라면 체감 가능한 대기 시간이 됩니다. WebP와 JXL이 더 균형 잡혀 있습니다. 브라우저 내 인코더(canvas.toBlob('image/avif'))는 네이티브 라이브러리보다 더 느립니다.

이미지 압축기 같은 인터랙티브 도구에서는 이것이 중요합니다. AVIF가 파일 크기에서는 최고지만, 실시간 미리보기의 지연이 눈에 띕니다.

EXIF와 메타데이터 동작

포맷	EXIF	IPTC	XMP	C2PA Content Credentials
JPEG	완전	있음	있음	있음(폭넓게 채택)
WebP	부분(디코더 의존)	부분	있음	부분
AVIF	있음(최신 디코더)	있음	있음	있음
JPEG XL	있음	있음	있음	있음

WebP와 AVIF의 EXIF 동작은 인코더와 디코더에 따라 달라집니다. 브라우저(특히 canvas.toBlob)는 WebP나 AVIF로 재인코딩할 때 EXIF를 떼어 냅니다. EXIF를 유지하려면 ImageMagick, libvips, sharp 같은 서버 측 도구가 필요합니다.

파이프라인을 거치는 동안 EXIF가 살아남는지에 대해 더 자세한 설명은 다음 글을 참고하세요. EXIF 데이터란 무엇인가? 와 iPhone 사진 메타데이터 완전 가이드.

저비트레이트에서의 품질

흥미로운 격전지는 시각적 무손실 품질이 아닙니다(현대 세 포맷 모두 거기까지 도달합니다). 진짜 차이가 나는 곳은 공격적으로 작은 파일 크기, 가령 느린 모바일 회선에 100 KB짜리 이미지를 내보내려 할 때입니다.

1080×1080 이미지를 100 KB로 만들면:

• JPEG: 블록 아티팩트가 눈에 띄고, 그러데이션(하늘, 피부)에서 색 띠가 생긴다.
• WebP: JPEG보다 그러데이션이 매끄럽지만 이 비트레이트에서는 약간 "흐릿한" 인상.
• AVIF: 눈에 띄게 더 좋다. 디테일을 살리고 WebP의 "흐릿함"을 피한다.
• JPEG XL: AVIF와 비슷하며, 디테일 보존이 조금 더 낫다.

모바일에서의 Core Web Vitals(LCP, CLS)에는 이 차이가 효과를 냅니다. 품질 70%의 AVIF는 품질 80%의 WebP보다 지각 가능한 차이 없이 30% 작게 나오는 경우가 많은데, 그것이 곧 페이지 로드 벤치마크에 그대로 반영됩니다.

어느 경우에 무엇을 고르는가(실용 결정 트리)

웹(페이지를 직접 통제):

• 기본: AVIF, WebP 폴백, JPEG 폴백. <picture> 요소를 사용한다.
• 모바일 우선 / Core Web Vitals 중시: AVIF가 정답.
• 더 단순한 운영(폴백 체인 없이): WebP. AVIF 대비 약 20% 파일 크기를 더 쓰지만 <picture> 없이 보편적 지원을 얻는다.

이메일 첨부 또는 공유 파일:

• 항상 JPEG. 메일 클라이언트는 WebP와 AVIF에서 일관성이 없다.

Apple 생태계(iOS 앱, Mac 전용 워크플로):

• JPEG XL이 진지한 선택지. Safari에서 네이티브 지원, 빠른 인코딩, JPEG로부터의 무손실 트랜스코딩이 가능.
• Apple 밖으로 공유할 때는 JPEG로 폴백.

CMS 또는 스톡 이미지 라이브러리:

• WebP. 보편적 지원, JPEG보다 작고, 폴백 복잡도 없음. 대부분의 CMS가 잘 서빙한다.
• 청중이 모바일 위주이고 CMS가 지원한다면 AVIF.

투명도가 있는 사진(로고, 제품 컷, UI):

• 투명도와 최소 크기를 동시에 원하면 AVIF.
• 보편 중도로는 WebP.
• 절대 무손실이 필요할 때만 PNG.

EXIF가 살아남아야 하는 사진 콘텐츠:

• JPEG(전체 체인에서 가장 신뢰할 수 있음).
• Apple 전용 맥락이면 JPEG XL.

변환과 테스트 방법

이미지 변환기는 JPG, PNG, WebP, AVIF, HEIC, GIF, BMP, ICO 사이의 변환을 브라우저 안에서 처리합니다. 파일을 드롭하고 출력 포맷을 고른 뒤 ZIP으로 일괄 다운로드. 업로드 없음.

품질 슬라이더가 있는 나란히 보기 라이브 압축 테스트에는 이미지 압축기를 쓰세요. 원본과 재압축본 미리보기가 옆에 나란히 뜨고, 절약된 정확한 바이트 수도 표시됩니다.

여러 입력 포맷을 한 번에 비교하고 싶으면 폴더를 변환기에 드롭하고 JPEG → WebP → AVIF 순으로 내보낸 다음, 결과 ZIP들을 비교하세요.

자주 묻는 질문

Chrome은 왜 JPEG XL을 뺐나? Google은 2022년 Chrome에서 JXL 디코더를 제거하면서, "더 넓은 생태계의 관심 부족"과 리소스 비용을 이유로 들었습니다. 결정은 논란이었습니다(개발자 청원, Mozilla의 열린 티켓, 사진가들의 반발). 2026년 현재 재추가는 발표되지 않았습니다.

WebP는 죽었나? 아니요. WebP는 보편적 지원에 폴백 복잡도가 없는 안전한 현대 포맷입니다. AVIF가 크기에서는 이기지만 운영 부담이 따라옵니다. 극단적이지 않은 대부분의 용도에서 WebP는 여전히 합리적인 기본값입니다.

AVIF가 정말 JPEG보다 50% 작아질 수 있나? 네, 사진 콘텐츠를 같은 시각 품질로 맞춘 경우. 합성 콘텐츠(로고, 스크린샷, 선화)처럼 무손실이나 준무손실이 더 어울리는 영역에서는 격차가 15~25%로 줄어듭니다.

WebP는 투명도를 보존하나? 네. 손실과 무손실 WebP 모두 8비트 알파를 지원합니다.

AVIF가 JPEG를 대체할까? 결국엔 그럴 가능성이 높습니다. JPEG는 빠르게 갈아치우기엔 너무 깊이 박혀 있지만, 모든 브라우저가 AVIF를 네이티브로 디코딩하고 모든 CDN이 그것을 서빙하는 흐름이 전환을 현실로 만들고 있습니다. 2030년이면 웹 사진의 기본은 AVIF일 가능성이 큽니다.

HEIC는 어떤가? HEIC와 HEIF는 AVIF와 같은 코덱 계열(모두 HEVC/AV1 시대 산물)입니다. HEIC는 Apple의 변형, AVIF는 개방 표준 사촌입니다. Apple 끼리의 워크플로에는 HEIC, 크로스플랫폼 웹에는 AVIF. HEIC 관점은 HEIC vs JPG를 참고하세요.

결론

2026년의 올바른 현대 포맷은 목표에 따라 다릅니다.

• 완전히 통제하는 웹: <picture>를 통해 WebP, JPEG 폴백과 함께 AVIF.
• 단순한 스택의 웹: WebP. 폴백 운영이 필요 없는 최고의 보편 현대 포맷.
• 이메일과 소셜: JPEG. 현대 포맷은 아직 여기서 안전하지 않습니다.
• Apple 전용 생태계: JPEG XL. 빠르고 작으며 네이티브 지원.

일회성 변환은 파일을 이미지 변환기에 드롭하세요. 배치와 실시간 미리보기 압축 테스트에는 이미지 압축기를 쓰세요. 둘 다 전적으로 브라우저 안에서 동작합니다.

iPhone 특유 맥락에서의 HEIC vs JPG 질문은 별도 가이드가 있습니다: HEIC vs JPG: 2026년에 어떤 포맷을 써야 할까?