WebP·JPG·PNG 차이: 이미지 형식은 무엇을 골라야 하나

투명 로고와 글자가 많은 캡처는 PNG로 전달하고, 웹에 올릴 사본의 용량을 줄일 때는 무손실 WebP와 비교하면 된다. 사진은 같은 픽셀 크기의 JPG와 손실 WebP를 비교해 필요한 세부가 남는 작은 사본을 고르고, 제출처의 호환성이 우선이면 JPG를 쓴다. 다만 16비트 PNG 원본을 보존하려는 경우에는 WebP의 무손실 모드로도 같은 정보를 담을 수 없어 PNG를 남겨야 한다.

JPG: 사진과 호환성이 중요할 때

JPG는 색상이 많은 사진을 비교적 작은 용량으로 저장하는 데 적합하다. 대부분의 편집 프로그램과 기기에서 바로 열린다. 다만 저장할 때 손실 압축이 적용되고 투명 배경은 지원하지 않는다. 같은 파일을 반복해서 편집하고 저장하면 화질이 더 떨어질 수 있다.

PNG: 투명 배경과 선명한 경계가 필요할 때

PNG는 무손실 압축과 투명 배경을 지원한다. 로고, 아이콘, 화면 캡처처럼 경계가 분명한 이미지에 적합하다. 사진을 PNG로 저장하면 화질은 유지되지만 파일 크기가 지나치게 커질 수 있다.

WebP: 웹페이지의 이미지 용량을 줄일 때

WebP는 손실·무손실 압축과 투명 배경을 모두 지원한다. 최신 브라우저에서 폭넓게 사용할 수 있어 웹사이트의 사진과 그래픽 용량을 줄이는 용도로 많이 쓰인다. 오래된 프로그램이나 특정 업로드 시스템이 WebP를 받지 않는다면 JPG나 PNG 사본을 함께 보관하는 편이 안전하다.

용도별 권장 형식

WebP와 PNG 차이: 둘 다 투명하지만 보존하는 정보가 다르다

PNG는 무손실 압축을 쓰고, WebP는 손실·무손실을 고를 수 있다. 둘 다 투명 배경을 담지만, PNG는 RGB의 채널당 16비트를 지원하고 WebP는 8비트까지 담는다. 일반적인 8비트 캡처를 줄일 때는 무손실 WebP를 비교하고, 16비트 원본을 보관할 때는 PNG를 유지한다.

MDN의 형식 안내도 사진에는 JPEG, 정밀한 재현이나 투명도가 필요하면 PNG 등을 고르도록 설명한다. JPG와 JPEG는 이 선택에서 같은 형식을 가리킨다. 파일 이름이 .jpg인지 .jpeg인지에 따라 화질 등급이 달라지는 것은 아니다.

예를 들어 풍경 사진을 메신저나 게시판으로 보내려면 호환성과 용량이 중요하다. 반면 표 계산 화면을 고객에게 보여 주려면 작은 숫자와 소수점이 읽혀야 한다. 사진에 쓰던 손실 압축 설정을 캡처에도 그대로 적용하면, 전체 화면은 비슷해 보여도 숫자 주변의 경계가 흐려질 수 있다.

PNG 계열에도 움직이는 APNG가 있다. W3C가 2025년 6월 24일 권고한 PNG 3판에는 애니메이션과 HDR 관련 정보가 포함돼 있다. ‘PNG는 정지 이미지만, WebP는 움직이는 이미지’라는 구분으로 고르면 맞지 않는다.

WebP와 JPG 차이: 사진은 같은 화질에서 용량을 비교한다

사진을 웹에 반복해서 띄운다면 손실 WebP 사본을 만들어 JPG와 비교한다. 이미 가진 JPG가 제출 용량 안에 들고 사진도 충분히 선명하다면 그대로 보내도 된다. 비교 사본을 만들 때는 원본의 픽셀 크기를 유지하고, 머리카락·나뭇잎·피부 질감이 받아들일 만한 수준인지 본 뒤 더 작은 쪽을 고른다.

흔히 인용하는 ‘WebP가 JPG보다 25~34% 작다’는 수치는 Google의 압축 연구에서 나왔다. 연구진은 같은 PNG 원본을 두 형식으로 압축하고, 원본과의 구조적 유사성을 재는 SSIM 값이 가깝도록 WebP 품질을 맞췄다. 아래는 JPG 품질75에 대응하는 결과다. 두 형식의 품질 슬라이더를 모두75로 둔 비교가 아니다.

이 연구에 쓰인 도구는 초기 버전인 libwebp 0.1.2와 libjpeg 6b다. 인코더는 이미지를 해당 형식의 파일로 압축하는 프로그램이다. 오늘 사용하는 프로그램이 이와 다르다면 압축 결과도 달라진다.

Cloudinary의 2024년 2월 말 버전 기준 비교에서는 약 100만 픽셀의 웹 이미지 묶음을 평균 SSIMULACRA2 점수60에 맞췄을 때, mozjpeg와 jpegli가 WebP보다 압축률과 처리 속도의 조합에서 유리했다. 이 비교에는 libwebp 1.3.2, mozjpeg 4.1.5, libjxl 0.10.0의 jpegli가 쓰였다. 같은 JPG라도 만드는 프로그램과 품질 조건에 따라 WebP로 바꿀 이익이 달라지는 것이다.

직접 JPG를 다시 최적화할 도구가 없다면 새 프로그램부터 찾을 필요는 없다. 지금 가진 JPG와 현재 쓰는 변환기가 만든 WebP 사본을 비교해, 용량이 줄고 필요한 세부가 남는 경우에만 바꾸면 된다. 카메라 원본이나 고해상도 편집본은 따로 보관하고 웹 게시용 사본에서 결정한다.

작은 컬러 글자는 품질100보다 무손실 설정이 중요하다

손실 WebP는 Google이 명시한 YUV 4:2:0 방식으로 색을 저장한다. 밝기 정보보다 색상 정보를 성기게 남겨 용량을 줄이는 방식이다. 작은 빨간 글자나 색이 다른 두 선이 맞닿은 캡처에서는 그 경계가 흐려질 수 있다. 품질100을 골라도 손실 WebP의 이 색상 저장 방식은 그대로다.

숫자·색 구분이 중요한 도표라면 PNG 또는 무손실 WebP를 쓴다. 이미 흐려진 손실 WebP를 PNG로 바꾸면 그 상태를 보관하므로, 선명한 원본 캡처에서 다시 저장한다. 로고도 배경의 투명도와 색 경계를 함께 보고, 투명 WebP라는 이유만으로 무손실이라고 판단하지 않는다.

PNG를 계속 써도 되는 경우: 제출·편집·16비트 원본 보관

PNG가 이미 제출 용량 안에 들어가고 받는 사람이 문제없이 연다면, 형식을 바꿀 필요가 없다. WebP로 얻는 이익은 주로 저장 공간과 웹 전송량이다. 회사 로고 한 장을 주고받는 일과 이미지 수백 장을 띄우는 웹사이트는 변환의 이익이 다르다.

• 메일·문서로 넘길 로고와 캡처: 투명도와 작은 글자를 보존하는 PNG가 편하다. 상대방 앱이 WebP를 받는지 알아보는 일을 줄인다.
• 웹사이트에 반복 노출할 이미지: 같은 크기의 무손실 WebP를 만들어 PNG와 용량을 비교한다. 사진이라면 손실 WebP도 후보에 넣는다.
• 색 보정을 이어갈 16비트 PNG: PNG 원본을 남기고 게시용 사본만 만든다. WebP는 각 색상 채널을 8비트로 담으므로 무손실 설정을 골라도 16비트 원본 전체를 보존하지 못한다.

비트 수는 색의 단계를 얼마나 세밀하게 기록하는지 나타낸다. WebP 무손실 규격은 8비트 채널을 쓰고, PNG 규격은 RGB의 16비트 채널을 지원한다. Adobe의 비트 심도 안내처럼 16비트에서 8비트로 바꿀 때는 사본으로 작업해야 원래의 정보를 남길 수 있다. PNG를 WebP로 바꾼 뒤 색상 프로필까지 복사해도 줄어든 비트 수가 되돌아오지는 않는다.

레이어·마스크를 다시 고칠 작업이라면 편집 프로그램의 원본 파일도 남긴다. 투명 PNG 한 장을 저장하는 것과 레이어별로 수정할 수 있는 파일을 보관하는 것은 다른 일이다. PPT에 넣은 사진의 일부를 가리는 작업까지 이어진다면 파워포인트에서 잘라낸 사진 영역을 파일에서도 지우는 방법도 함께 적용한다.

JPG를 PNG로 바꾸면 화질이 좋아지는가

이미 손실 압축으로 버린 정보를 PNG로 저장하는 것만으로 되살릴 수는 없다. PNG가 무손실이라는 뜻은 저장할 때 받은 픽셀 정보를 손실 압축하지 않는다는 의미다. 처음 촬영한 이미지의 모든 정보를 찾아 복원한다는 의미가 아니다.

흐린 JPG를 PNG로 바꿨더니 용량만 커졌다면 이상한 현상이 아니다. JPG를 열었을 때 보이는 흐림과 압축 흔적까지 PNG가 보관한다. Google의 WebP FAQ도 손실 이미지에서 무손실 WebP나 PNG로 옮기면 손실 흔적을 그대로 담느라 파일이 커질 수 있다고 설명한다.

PNG로 작업 사본을 만드는 일에는 여전히 용도가 있다. 이미지를 고치고 다시 저장하는 동안 손실 압축을 반복하지 않을 수 있기 때문이다. 다만 처음부터 선명한 원본이 있다면 그 원본에서 편집을 시작하는 편이 낫다. 저화질 JPG를 PNG로 바꾼 뒤 확대하는 방식으로 원본을 대신하지 않는다.

‘무손실 PNG인데 캡처 글자가 깨졌다’면 원본과 사본의 가로·세로 픽셀 크기를 비교한다. 가로 2000픽셀인 화면을 500픽셀로 축소하면 글자에 쓰일 픽셀 자체가 줄어든다. 그 결과를 PNG로 저장해도 축소 전의 글자가 돌아오지는 않는다. 변환과 리사이즈를 함께 했다면, 먼저 원본 크기 그대로 변환한 사본과 비교해 축소가 선명도에 미친 영향을 확인한다.

WebP로 바꿨는데 용량이 커지면 원본과 압축 모드를 본다

WebP의 용량이 항상 JPG나 PNG보다 작은 것은 아니다. 원본이 이미 많이 압축됐는지, 색이 적은 그래픽인지, 손실·무손실 중 무엇을 골랐는지에 따라 결과가 달라진다. Google FAQ의 용량 증가 설명에는 이 차이를 만드는 사례가 나와 있다.

먼저 이미 작은 JPG를 무손실 WebP로 저장하면 현재 보이는 픽셀과 압축 흔적을 보관하는 데 더 많은 공간이 들 수 있다. 반대로 색이 몇 개 안 되는 PNG를 손실 WebP로 만들 때도 용량이 늘 수 있다. 손실 압축으로 생긴 새로운 색 변화가 원래 단순했던 그림을 더 복잡하게 만들기 때문이다.

품질 값을 높게 잡은 경우도 있다. 작은 JPG를 높은 품질의 손실 WebP로 다시 저장하면, 그 파일이 더 커졌다는 사실만으로 화질이 복구됐다고 판단할 수 없다. 지금 가진 이미지에서 더 크게 저장한 결과일 수 있다. 필요한 표시 크기와 원본 상태에 맞춰 출력 설정을 고른다.

실제로 개발자 effiRin은 2023년 12월 공개한 서비스 이미지 변환 실험에서 JPG 100장을 골라 품질과 압축 모드를 바꿨다. 손실 WebP 품질100에서는 30장의 용량이 원본 JPG보다 늘었다. 이 표본에서는 높은 품질 숫자를 고르는 것만으로 용량 절감이 끝나지 않았고, 저자도 자기 서비스 이미지에서 결과를 비교하라고 결론 냈다.

Google의 WebP 개요에 있는 용량 절감 수치도 비교 조건이 붙은 연구 결과다. 같은 화질 지표에서 비교한 JPG와 손실 WebP, PNG와 무손실 WebP의 결과를 자기 파일마다 보장되는 비율로 계산하지 않는다. 형식이 다른데 품질 슬라이더 숫자만 같다고 같은 화질이라고 볼 수도 없다.

비교할 때는 같은 원본에서 같은 가로·세로 픽셀 크기로 만든다. WebP만 작게 축소해 놓고 PNG보다 용량이 줄었다고 평가하면 형식과 크기 변경의 효과가 섞인다. 사진의 머리카락·나뭇잎·그러데이션, 캡처의 작은 글자·얇은 선처럼 차이가 잘 보이는 부분을 먼저 대조한다.

확대 비율도 맞춘다. 한 파일은 화면에 맞게 축소하고 다른 파일은 100%로 열면 글자의 굵기와 선명도가 다르게 보인다. 먼저 같은 배율에서 원본과 사본을 번갈아 보고, 실제 게시할 크기에서도 읽히는지 확인한다. 웹 본문에서 작은 크기로 쓸 사진과 확대해서 세부를 읽어야 하는 도표는 허용할 수 있는 손실이 다르다. 파일 크기만 작아졌다는 이유로 도표의 소수점이나 로고의 얇은 획이 사라진 결과를 고르지 않는다.

실측에서도 PNG 최적화와 WebP 변환의 이익은 파일마다 달랐다

Demetris가 2025년 10월 공개한 무손실 이미지 압축 비교는 같은 이미지에 여러 도구와 설정을 적용했다. 아래는 Debian 13의 cwebp 1.5.0과 oxipng 9.1.5 결과 중 두 파일이다. 단위는 모두 바이트다. 최적화 PNG는 oxipng의 --opt max --zopfli, WebP는 원문 표의 -lossless -mt -z 9 -exact 설정 결과다.

이 두 사례에서는 PNG 형식을 유지하면서도 용량이 줄었고, 무손실 WebP는 더 작았다. 웹페이지의 큰 캡처라면 변환을 검토할 이유가 있지만, 이미 수만 바이트인 로고 하나를 전달하는 일이라면 PNG의 편리함을 택해도 된다. 위 수치를 사진이나 모든 로고의 절감률로 적용할 수는 없다.

변환 도구가 이미지 크기도 함께 줄였는지 살피는 것도 중요하다. Suzanne Scacca의 모바일 이미지 최적화 실습에서는 사진의 픽셀 크기와 압축 설정을 함께 바꿔 큰 폭으로 용량을 줄였다. 이처럼 리사이즈까지 한 결과를 파일 형식 하나의 효과로 읽으면 잘못된 비교가 된다. 자신의 파일은 필요한 출력 크기를 먼저 정한 뒤 그 크기에서 형식별 사본을 비교하면 된다.

투명 로고를 JPG로 바꾸면 배경을 정해야 한다

JPG는 투명도를 지원하지 않으므로 투명 PNG나 WebP를 JPG로 만들면 투명했던 부분을 어떤 색으로 채울지 정해야 한다. 흰 배경의 문서에 붙일 로고라면 흰색으로 합성할 수 있지만, 어두운 화면에도 쓸 로고라면 PNG나 투명 WebP 사본을 남기는 편이 맞다.

흰 화면에서만 로고를 열어 보면 흰색으로 채운 배경과 투명 배경이 비슷해 보인다. 편집기의 투명도 표시나 어두운 배경 위에서 한 번 더 보면 차이를 찾기 쉽다. 글자와 테두리 주변에 밝은 테두리가 남는지도 살핀다. 투명도를 지원하는 형식을 골랐더라도 변환 도구에서 배경을 합성해 저장했다면 투명한 결과가 아니다.

가령 웹 배너에는 흰색 배경이 항상 붙고, 회사 PPT에는 여러 색 배경을 쓴다고 하자. 웹 게시판이 JPG만 받는다면 흰 배경 JPG 사본을 쓰고, PPT에는 투명 PNG를 쓸 수 있다. 두 파일을 ‘로고_흰배경.jpg’, ‘로고_투명.png’처럼 구분하면 투명을 잃은 파일을 다음 편집의 원본으로 착각하기 어렵다.

파일 이름 변경 대신 새 형식으로 저장한다

파일 이름의 .webp를 .jpg로 고쳐도 이미지 내부의 압축 데이터는 바뀌지 않는다. 받는 프로그램이 파일 내용을 읽으면 여전히 WebP로 판단하거나 형식 불일치로 거절할 수 있다. 지원되는 편집기나 변환기에서 열고 새 형식을 선택해 별도 사본으로 저장한다.

일반 편집기에서는 원본을 연 뒤 ‘다른 이름으로 저장’이나 ‘내보내기’에서 JPG·PNG를 고른다. 도구마다 메뉴가 다르므로 파일명 입력칸만 바꾸지 않고 출력 형식 항목을 본다. Adobe Express 공식 안내의 경우에는 사진 빠른 작업에서 JPG 또는 PNG 변환을 골라 파일을 넣고 내려받는 순서다.

Photoshop 23.2 이상은 WebP를 기본으로 지원한다. Adobe가 안내하는 저장 경로는 파일 → 사본 저장(File → Save a Copy) → 형식 WebP다. 다음 옵션 창에서 캡처는 Lossless, 사진은 용량과 세부 묘사를 비교하며 Lossy를 고른다. WebP 저장은 8비트 RGB 문서를 대상으로 한다. 16비트 문서에서 형식을 찾느라 원본의 모드를 바로 바꾸지 말고 사본부터 만든다.

명령줄을 사용하는 사람은 Google의 cwebp와 dwebp를 쓸 수 있다. 다음은 해당 도구가 설치된 환경에서 실행할 정지 이미지용 명령 예시다.

cwebp -q 80 photo.jpg -o photo-web.webp
cwebp -lossless capture.png -o capture-lossless.webp
dwebp logo.webp -o logo.png

cwebp의 첫 명령은 사진을 품질80의 손실 WebP로 저장하고, 둘째는 8비트 캡처를 무손실 WebP로 저장한다. 첫 사본에서 세부 묘사와 용량을 비교한 뒤 품질 값을 조절한다. 손실 모드에서 품질100을 골라도 무손실 모드를 선택한 것과 같지 않다. 투명 영역 안의 보이지 않는 RGB 값까지 보존해야 하는 작업에는 무손실 명령에 -exact도 붙인다.

dwebp의 셋째 명령은 WebP를 PNG로 푸는 예시다. 이 도구는 애니메이션 WebP를 지원하지 않는다. 움직이는 이미지라면 정지 이미지용 변환에 그대로 넣지 않고 애니메이션을 보존하는 별도 기능이 필요하다. 정지 사진을 바꾸는 절차를 움직이는 모든 WebP에 적용하지 않는다.

무손실로 저장해도 촬영정보까지 자동 보존되지는 않는다

이미지의 픽셀을 보존하는 압축 방식과 파일에 붙은 부가정보를 복사하는 설정은 다르다. Google의 cwebp 문서에서 메타데이터 복사 옵션 -metadata의 기본값은 none이다. 앞의 무손실 변환 명령도 이 옵션을 따로 넣지 않았으므로 촬영정보나 색상 프로필까지 복사하는 명령은 아니다.

ICC는 색을 해석하는 데 쓰는 프로필이고, EXIF·XMP는 촬영·편집 관련 부가정보를 담는 데 쓰인다. 원본에 있는 ICC 프로필을 함께 복사하려면 아래처럼 지정한다. 모든 지원 메타데이터를 복사하는 값은 all이지만, 실제로 복사할 수 있는 정보는 입력 형식과 원본에 들어 있는 내용에 따라 달라진다.

cwebp -lossless -metadata icc capture.png -o capture-profile.webp
webpmux -info capture-profile.webp

첫 명령은 무손실 압축과 ICC 복사를 함께 요청한다. 색을 특정 색공간으로 변환하거나, 원본에 없는 프로필을 만드는 명령은 아니다. 둘째 명령은 webpmux가 설치된 환경에서 결과 WebP의 구성 정보를 보는 방법이다. 촬영정보까지 남겨야 하는 보관용 파일이라면 원본을 유지하고 필요한 항목이 사본에도 있는지 대조한다. 다른 변환기를 쓸 때도 메타데이터 저장 항목을 살핀다. cwebp의 기본값을 모든 변환기의 동작으로 적용할 수는 없다.

저장한 사본은 실제 제출할 곳에서 다시 연다

내보낸 파일을 다시 열어 가로·세로 크기, 작은 글자, 배경 투명도와 파일 크기를 확인한다. 용량 제한을 넘었다면 픽셀 크기와 압축 품질 중 어느 조건을 바꿨는지 기록하며 다시 저장한다. 두 조건을 한꺼번에 크게 낮추면 어떤 변경 때문에 읽기 어려워졌는지 찾기 어렵다.

색이나 촬영정보도 작업의 일부라면 같은 앱에서 원본과 사본을 열어 보고, 필요한 프로필과 정보가 남았는지도 확인한다. 화면에서 사진이 비슷해 보이는 것만으로 파일에 붙은 정보까지 같다고 판단하지 않는다.

브라우저에서 열린다는 사실과 제출 사이트가 그 형식을 받는다는 사실도 다르다. 업로드 안내가 JPG·PNG만 허용한다면 그 형식의 사본을 사용한다. 원본은 보관하고 사본만 변환하면 다른 곳에서 투명도나 더 큰 크기가 필요할 때 다시 시작할 수 있다. 이미 줄인 파일을 계속 다시 저장하기보다 원본에서 필요한 사본을 각각 만든다.

웹에서 JPG를 내려받으려 했는데 WebP가 저장되는 경우도 있다. Ilya Grigorik은 자신의 사이트를 이용한 설명에서 같은 이미지 주소라도 서버가 브라우저에 맞춰 다른 형식으로 응답하는 사례를 보여 줬다. 주소 끝이 .jpg인지보다 내려받은 파일의 실제 형식과 제출처의 허용 형식이 중요하다. 저장된 파일이 WebP라면 앞의 변환 절차로 JPG·PNG 사본을 만든다.

이미지를 문서로 묶어 보내는 경우에는 형식을 바꾸는 것과 문서 안의 정보를 지우는 일을 구별한다. 이름이나 연락처를 가린 자료를 전달한다면 PDF 개인정보를 검은 상자로 가렸을 때 남는 정보까지 처리한 뒤 제출한다.

자료 기준: 2026년 11월 6일 공식 규격·도구 안내와 외부 실측·실습을 대조했다. 압축 표는 외부 작성자의 측정값이며 이 글에서 직접 변환·측정한 결과는 아니다.