favicon.ico에는 어떤 크기를 담아야 하나요?
16, 32, 48px 이 셋이 브라우저 탭, Alt-Tab 전환기, 바탕 화면을 감당하며 1995년부터 권장되어 온 조합입니다. 256은 아이콘이 큰 아이콘 보기에서도 버텨야 할 때만 더하십시오.
PNG를 ICO로 변환 (ICO → PNG 추출도 지원)
PNG, JPG, SVG, WebP를 다중 크기 .ico로 온라인 변환합니다. 16·32·48px를 한 파일에 담고 알파 채널을 보존하며, 내장 PNG와 비압축 BMP 용량을 함께 표시합니다.
트래킹 없음 브라우저 실행 무료
변환은 전부 브라우저 안에서 이루어집니다. 이미지는 업로드되지 않습니다.
이미지를 여기에 놓거나 클릭하여 선택
PNG, JPG, SVG, WebP, GIF, BMP · 최대 10MB
둘 다 .ico 안에서 유효합니다. PNG는 Vista 이후의 Windows와 현재 모든 브라우저가 읽습니다. 한편 20개 사이트를 표본으로 살펴 찾아낸 진짜 ICO 파일 14개 가운데 13개는 비압축 BMP였는데, ImageMagick이 기본적으로 그쪽으로 변환하기 때문입니다.
<link rel="icon" href="/favicon.ico" sizes="16x16 32x32 48x48"> <link rel="icon" type="image/svg+xml" href="/icon.svg"> <link rel="apple-touch-icon" href="/apple-touch-icon.png">
.ico 파일을 여기에 놓거나 클릭하여 선택
파일 안의 모든 크기를 따로따로 나열합니다
.ico 파일 안에 들어 있는 것 (16 + 32 + 48px 예시)
| 오프셋 | 바이트 | 필드 | 값 |
|---|---|---|---|
| 0 | 2 | idReserved | 0 |
| 2 | 2 | idType | 1 |
| 4 | 2 | idCount | 3 |
| 6 | 1 | bWidth[0] | 16 → 16 |
| 7 | 1 | bHeight[0] | 16 → 16 |
| 8 | 1 | bColorCount[0] | 0 |
| 9 | 1 | bReserved[0] | 0 |
| 10 | 2 | wPlanes[0] | 1 |
| 12 | 2 | wBitCount[0] | 32 |
| 14 | 4 | dwBytesInRes[0] | 248 |
| 18 | 4 | dwImageOffset[0] | 54 |
| 22 | 1 | bWidth[1] | 32 → 32 |
| 23 | 1 | bHeight[1] | 32 → 32 |
| 24 | 1 | bColorCount[1] | 0 |
| 25 | 1 | bReserved[1] | 0 |
| 26 | 2 | wPlanes[1] | 1 |
| 28 | 2 | wBitCount[1] | 32 |
| 30 | 4 | dwBytesInRes[1] | 720 |
| 34 | 4 | dwImageOffset[1] | 302 |
| 38 | 1 | bWidth[2] | 48 → 48 |
| 39 | 1 | bHeight[2] | 48 → 48 |
| 40 | 1 | bColorCount[2] | 0 |
| 41 | 1 | bReserved[2] | 0 |
| 42 | 2 | wPlanes[2] | 1 |
| 44 | 2 | wBitCount[2] | 32 |
| 46 | 4 | dwBytesInRes[2] | 1464 |
| 50 | 4 | dwImageOffset[2] | 1022 |
이 페이지에 인용한 16진 덤프, 바이트 수, 명령 출력은 이 도구가 실제로 생성한 파일에서 가져왔습니다. 디코더 동작에 관한 모든 주장은 서로 독립적인 세 구현, 즉 처음부터 직접 작성한 인코더, Pillow 12.3.0, Chromium 자체 ICO 디코더로 교차 검증했습니다. 배포 중인 파비콘 대부분이 비압축 비트맵을 쓴다는 관찰은 2026년 9월에 잘 알려진 20개 사이트의 아이콘 파일을 내려받아 파싱한 결과입니다. — Go Tools 엔지니어링 팀 · Sep 22, 2026
Go Tools 변환 도구를 개발하는 개발자들이 작성하고 검토했습니다. 여기 설명한 컨테이너 구조, 바이트 수, 실패 양상은 남이 이 포맷을 요약한 글이 아니라 문서로 남긴 도메인 검토에서 나온 것입니다.
PNG ICO 변환 빠른 답변
하나의 .ico에 여러 크기를 담을 수 있나요?
네, 바로 그러라고 있는 포맷입니다 이 포맷 자체가 컨테이너입니다. 6바이트 헤더, 이미지마다 16바이트 디렉터리 엔트리, 그다음이 이미지입니다. 각각이 따로 그린 그림이며, 좋은 아이콘이 16px에서도 또렷한 이유가 여기 있습니다.
PNG를 ICO로 변환하면 투명도가 사라지나요?
제대로 하면 사라지지 않습니다 .ico 안에 이미지를 저장하는 두 방식 모두 8비트 알파 채널을 온전히 담습니다. 투명도는 도구가 알파 바이트를 비워 두거나, 오래된 소프트웨어가 대신 읽는 1비트 마스크를 빠뜨릴 때만 사라집니다.
.ico 안의 256px 레이어는 용량이 얼마인가요?
비압축 264KB, PNG로는 몇 KB 비압축 256px 레이어는 정확히 270,376바이트입니다. 헤더 40바이트, 픽셀 262,144바이트, 마스크 8,192바이트이며 그림이 무엇이든 같습니다. 같은 레이어를 PNG로 저장하면 대개 몇 KB면 됩니다.
ICO 파일이란 무엇인가요?
.ico는 이미지 포맷이라기보다 이미지를 모아 둔 작은 아카이브에 가깝습니다. 안에 그림이 몇 장 들었는지 알려 주는 6바이트 헤더로 시작해, 그림 한 장마다 너비·높이·바이트 수·파일 내 위치를 담은 16바이트 디렉터리 엔트리가 이어지고, 그다음에 그림 데이터 자체가 옵니다. 각 그림은 두 가지 방식 중 하나로 저장됩니다. 완전한 PNG 파일을 통째로 내장하거나, 1비트 투명 마스크를 아래에 덧붙인 비압축 Windows 비트맵으로 담는 것입니다.
이 설계 덕분에 파비콘 하나가 브라우저 탭에서는 16px로, 파일 탐색기에서는 48px로 모두 선명하게 보입니다. 한 이미지를 늘였다 줄였다 하는 것이 아니라 크기마다 따로 다듬어 그린 별개의 그림이기 때문입니다. 같은 설계에서 몇 가지 뜻밖의 성질도 나옵니다. 변의 길이가 1바이트에 저장되므로 256은 0으로 적히고 512는 아예 적을 수 없습니다. 또 디렉터리가 엔트리마다 크기를 기록하는데 이미지 데이터도 같은 크기를 기록하므로 둘이 어긋날 수 있고, 소프트웨어마다 믿는 쪽이 다릅니다.
$ file favicon.ico
favicon.ico: MS Windows icon resource - 3 icons, 16x16, 32 bits/pixel, 32x32, 32 bits/pixel
$ python3 -c "from PIL import Image; print(sorted(Image.open('favicon.ico').ico.sizes()))"
[(16, 16), (32, 32), (48, 48)] 이 ICO 변환기가 하는 일
한 파일에 선택한 모든 크기
기본은 16, 32, 48px이며 최대 256px까지 담습니다. 각 크기는 위 레이어에서 줄이는 대신 원본에서 전체 품질로 따로 그려지므로, 작은 크기가 큰 크기의 뭉개짐을 물려받지 않습니다.
PNG 또는 비압축 BMP, 두 용량을 모두 표시
컨테이너가 허용하는 두 페이로드 형식은 장단점이 크게 다른데도, 자기가 어느 쪽을 쓰는지 밝히는 변환기는 거의 없습니다. 여기서는 스위치로 제공하고 각각의 결과 용량까지 표시하므로 짐작이 아니라 숫자로 결정할 수 있습니다.
어느 경로로 가도 살아남는 투명도
알파 채널을 온전히 기록하고, 오래된 소프트웨어가 대신 읽는 1비트 마스크도 비워 두지 않고 알파에서 유도합니다. 그 마스크를 비워 두는 것이 마스크만 읽는 환경에서 투명 아이콘이 검은 사각형으로 변하는 원인입니다.
내려받기 도구가 아니라 ICO 뷰어
반대 방향 탭은 .ico 안의 모든 이미지를 실제 크기, 저장 형식, 비트 심도, 투명도의 출처와 함께 나열합니다. 잘 알려진 몇몇 파비콘이 여전히 쓰는 팔레트 기반 비트맵도 포함됩니다. 브라우저는 그중 한 장만 보여 줍니다.
파일이 앞뒤가 맞지 않으면 알려 줌
디렉터리가 주장하는 크기와 이미지 데이터가 맞지 않으면 표시합니다. Firefox가 버리는 내장 PNG도 함께 표시합니다. Firefox의 ICO 디코더는 8비트 RGB나 RGBA만 받으므로 팔레트나 그레이스케일 레이어는 거기서만 사라지고, 다른 브라우저에서는 모두 정상적으로 보입니다. 둘 다 아이콘이 한 프로그램에서는 나오고 다른 프로그램에서는 빈칸으로 뜨는 흔한 원인인데, 어느 쪽이든 알려 주는 변환기는 달리 없습니다.
업로드 없음
읽기, 크기 조정, 포장이 모두 이 페이지 안에서 이루어집니다. 파일이 서버에 닿지 않으므로 나중에 지울 것도, 기다릴 대기열도 없습니다.
코드로 PNG를 ICO로 변환하기
ImageMagick
magick in.png -define icon:auto-resize=48,32,16 favicon.ico 가장 흔한 답이자 그토록 많은 파비콘이 비압축인 이유입니다. 256px를 제외한 모든 레이어를 포장 전에 비트맵으로 변환하므로 세 크기가 수백 바이트가 아니라 15KB 안팎으로 나옵니다. 크기는 큰 것부터 기록됩니다.
Python + Pillow
img.save('favicon.ico', sizes=[(16,16),(32,32),(48,48)]) PNG를 내장하므로 같은 세 크기가 대략 10분의 1 공간에 들어갑니다. Pillow는 ICO 읽기도 잘합니다. Image.open(f).ico.sizes()가 안에 무엇이 있는지 알려 주어 남의 파일을 점검할 때 편리합니다.
png-to-ico (npm)
npx png-to-ico icon.png > favicon.ico PNG 하나 이상을 받아 PNG 페이로드로 포장하는 단일 목적 CLI입니다. 빌드 스크립트에 넣기 편하지만 크기 조정은 대신해 주지 않으므로 각 크기를 개별 파일로 직접 준비해야 합니다.
sharp
sharp(input).resize(32).png() 개별 PNG를 뽑는 데는 훌륭하지만 ICO 컨테이너는 쓰지 못하므로 보통 위의 포장 도구 중 하나와 함께 씁니다. 빌드 파이프라인이 이미 sharp로 표준화되어 있을 때 흔히 혼란이 생기는 지점입니다.
Go
github.com/Kodeworks/golang-image-ico image.Image에서 이미지 한 장짜리 ICO를 기록합니다. 크기 하나짜리 파비콘에는 충분하지만, 여러 크기를 한 컨테이너에 담으려면 디렉터리를 직접 써야 하며 대략 서른 줄 분량입니다.
Windows 아이콘 컴파일러
.rc 리소스 스크립트, rc.exe 애플리케이션 아이콘을 뽑는 일반적인 방법입니다. 컴파일러가 .ico를 실행 파일의 리소스 섹션에 내장하며, 그 안의 컨테이너는 웹 파비콘과 정확히 같은 형식입니다.
GIMP
파일 → 다른 이름으로 내보내기 →.ico 이미지의 각 레이어를 아이콘 크기 하나로 내보내고, 압축 PNG를 포함해 레이어별로 비트 심도를 고를 수 있게 합니다. 이 선택을 조용히 대신 결정하지 않고 드러내 보여 주는 몇 안 되는 그래픽 도구입니다.
macOS sips
sips -s format ico in.png --out favicon.ico macOS에도 ICO 쓰기 기능은 실제로 있습니다. sips --formats는 com.microsoft.ico를 쓰기 가능으로 표시하며, 위 명령은 여기서 유효한 파일을 만들어 냈습니다. 못 하는 것은 여러 크기를 한 파일에 담는 일로, 출력은 48×48 한 장뿐이었습니다. 검색 결과가 대신 권하는 iconutil은 Apple 고유 컨테이너인 .icns를 만들며, 이는 Windows와 브라우저가 읽지 못합니다.
PNG ICO 변환 예시, 바이트 단위로
크기 세 개가 담긴 .ico의 첫 38바이트
$ xxd -l 38 favicon.ico
00000000: 0000 0100 0300 1010 0000 0100 2000 e903 ............ ... 00000010: 0000 3600 0000 2020 0000 0100 2000 6c05 ..6... .... .l. 00000020: 0000 1f04 0000 ......
0000은 예약 필드, 0100은 타입 1(커서가 아니라 아이콘), 0300은 이미지가 세 개라는 뜻입니다. 이어지는 것이 첫 번째 16바이트 디렉터리 엔트리입니다. 10 10은 16×16, 00은 색상 수, 00은 예약, 0100은 평면 하나, 2000은 픽셀당 32비트, e903 0000은 페이로드가 1,001바이트라는 뜻이며 그 위치는 3600 0000 = 54입니다. 54는 정확히 6 + 3 × 16, 즉 디렉터리의 끝입니다. 한 바이트로 저장되는 크기를 빼면 여러 바이트로 된 값은 모두 리틀 엔디언입니다.
256px 엔트리에는 256이 아니라 0이 들어간다
bWidth = 0x00 bHeight = 0x00
256 × 256
디렉터리는 각 변을 1바이트로만 담기 때문에 표현할 수 있는 최댓값이 255이며, 0이 256을 뜻하도록 정의되어 있습니다. 이 페이지 어디에도 512px가 없는 이유도 같습니다. 512를 담을 수 있는 바이트가 아예 없습니다. 그런데도 512px를 제공하는 온라인 변환기가 적지 않고, 이들은 자기 뒤에 오는 이미지를 설명하지 못하는 디렉터리 엔트리를 씁니다.
같은 세 크기, 두 가지 저장 방식
16 + 32 + 48 px, PNG payloads 16 + 32 + 48 px, uncompressed BMP payloads
389 bytes 15,086 bytes
비압축 페이로드의 비용은 40 + 너비 × 높이 × 4바이트에 1비트 마스크를 더한 값이라, 크기는 치수에만 달려 있고 그림 내용과는 전혀 무관합니다. 서로 아무 관련 없는 세 사이트가 길이가 바이트 단위로 똑같은 파비콘을 배포할 수 있는 이유입니다.
명령줄에서 같은 파일 생성하기
$ magick logo.png -define icon:auto-resize=48,32,16 favicon.ico $ file favicon.ico
favicon.ico: MS Windows icon resource - 3 icons, 48x48, 32 bits/pixel, 32x32, 32 bits/pixel
ImageMagick은 256px를 제외한 모든 레이어를 비압축 비트맵으로 변환한 뒤 포장하므로, 결과물이 수백 바이트가 아니라 15KB 안팎이 됩니다. Pillow는 반대로 PNG를 내장합니다: Image.open('logo.png').save('favicon.ico', sizes=[(16,16),(32,32),(48,48)]).
.ico를 다시 풀어헤치기
$ magick favicon.ico favicon-%d.png
favicon-0.png 48×48 favicon-1.png 32×32 favicon-2.png 16×16
브라우저가 대신해 줄 수 있는 일이 아닙니다. 다중 크기 .ico를 <img> 태그에 넘기면 크기가 어떤 순서로 들어 있든 돌아오는 이미지는 딱 하나, 가장 큰 것뿐입니다. 파일 안에 실제로 무엇이 들었는지 나열하려면 컨테이너를 직접 파싱해야 하고, 그것이 ICO → PNG 탭이 하는 일입니다.
PNG를 ICO로 변환하는 방법
- 1
이미지 끌어다 놓기
PNG, JPG, SVG, WebP, GIF, BMP를 모두 받으며 최대 10MB까지 허용됩니다. 파일은 브라우저 밖으로 나가지 않습니다. File API로 읽어 들이고 모든 픽셀은 로컬 canvas에 그려집니다.
- 2
크기 선택
처음에는 16, 32, 48px가 선택되어 있습니다. 큰 아이콘 보기나 고해상도 데스크톱에서도 버텨야 한다면 64, 128, 256을 추가하십시오. 원본이 선택한 최대 크기보다 작으면 조용히 확대하지 않고 페이지가 그 사실을 알려 줍니다.
- 3
저장 형식 선택
기본값은 PNG입니다. 용량이 한 자릿수 배 작고 현재 모든 브라우저와 Vista 이후의 모든 Windows가 읽을 수 있기 때문입니다. 실제로 배포되는 파비콘 대부분의 형태를 원한다면 비압축 BMP로 전환하십시오. 두 용량은 나란히 표시됩니다.
- 4
내려받아 연결하기
.ico를 저장하고, 마크업이 필요하면 link 태그 복사 버튼을 사용하십시오. 루트의 /favicon.ico 경로는 여전히 대비책으로 동작하지만, 브라우저가 먼저 시도하도록 명시된 경로는 link 요소입니다.
ICO 파일이 잘못되는 이유
256px 레이어를 255로 적기
256px 이미지에 해당하는 디렉터리 바이트는 반드시 0이어야 합니다. 255로 적는 것은 무해한 1 차이처럼 보이지만, 일부 브라우저가 조용히 그리기를 거부하는 파일을 낳습니다.
✗ 오류
bWidth = 0xFF bHeight = 0xFF ; 256을 뜻하려던 "255"
✓ 정상
bWidth = 0x00 bHeight = 0x00 ; 0이 256을 뜻하도록 정의됨
디렉터리와 이미지가 크기를 두고 엇갈림
디렉터리 엔트리는 16×16이라 하는데 페이로드가 실제로는 32×32이면 디코더가 갈립니다. 어떤 디코더는 디렉터리를 믿고 아무것도 그리지 않고, 어떤 디코더는 페이로드를 믿고 멀쩡히 렌더링합니다. 그러면 그 파일은 한 컴퓨터에서는 잘 되고 다른 컴퓨터에서는 보이지 않습니다.
✗ 오류
entry: 16×16 payload IHDR: 32×32
✓ 정상
entry: 32×32 payload IHDR: 32×32
비트맵 높이 필드를 두 배로 하지 않음
비압축 레이어 안에서 높이는 색상 데이터와 마스크를 함께 포함합니다. 그냥 높이를 적으면 어떤 디코더에서는 빈 화면으로, 어떤 디코더에서는 이미지의 아래 절반으로 보이는 파일이 되며 양쪽 다 오류를 내지 않습니다.
✗ 오류
biHeight = 32 ; 32px 이미지의 경우
✓ 정상
biHeight = 64 ; 2 × 32, 색상 데이터와 마스크
알파 채널이 비어 있는 비압축 레이어
어떤 도구는 마스크만 채우고 알파 바이트를 전부 0으로 남깁니다. 한 디코더는 이를 완전히 투명한 이미지로 읽어 아이콘이 사라지고, 다른 디코더는 마스크로 되돌아가 제대로 보여 줍니다. 둘을 일관되게 모두 기록하면 이 논쟁 자체를 피할 수 있습니다.
✗ 오류
alpha bytes: all 0x00 mask: all 0x00
✓ 정상
alpha bytes: real values mask: set where alpha < 128
인터넷에서 파일을 끌어오는 SVG
SVG 내부의 외부 참조는 래스터화할 때 차단되며 그 사실을 아무도 알려 주지 않습니다. 오류도 나지 않고 canvas도 계속 읽을 수 있습니다. 깨진 이미지 자리 표시자만 아이콘에 그대로 구워집니다. 변환하기 전에 도안을 인라인으로 넣으십시오.
✗ 오류
<image href="https://cdn.example.com/logo.png"/>
✓ 정상
<image href="data:image/png;base64,iVBORw0KGgo…"/>
PNG ICO 변환기가 필요할 때
- 새 사이트에 파비콘 넣기
- 로고를 끌어다 놓고 기본 세 크기를 그대로 두어 favicon.ico를 내려받은 뒤 웹 루트에 넣으면 됩니다. 복사되는 link 태그에는 같은 아이콘의 최신 마크업이 SVG, Apple 터치 아이콘과 함께 들어 있습니다.
- 크게는 멀쩡하고 작게는 뭉개지는 아이콘 고치기
- 보통은 파일에 큰 레이어 하나만 있고 나머지는 브라우저가 줄인 결과입니다. 256px 판이 아니라 원본에서 그린 진짜 16px 레이어를 넣는 것이 해결책입니다.
- 데스크톱 애플리케이션에 아이콘 주기
- Windows 실행 파일, 설치 관리자, 바로 가기는 .ico를 받고, 셸의 위치마다 같은 파일에서 서로 다른 크기를 꺼내 씁니다. 16, 32, 48, 256을 담으면 목록의 작은 아이콘, Alt-Tab 전환기, 큰 아이콘 보기를 모두 감당합니다.
- 아이콘이 어떤 곳에서만 보이는 이유 찾기
- ICO → PNG 탭에서 파일을 여십시오. 디렉터리가 잘못 적은 크기, 알파가 아예 없는 레이어, 중간에 잘린 엔트리가 모두 목록에 드러납니다. 옆 레이어가 망가져 있어도 정상인 레이어는 각각 그대로 내보내집니다.
- 오래된 .ico에서 PNG 되찾기
- 예전 프로젝트에서 물려받은 아이콘이 어떤 로고의 유일한 사본인 경우가 많습니다. 반대 방향 탭은 각 레이어를 개별 PNG로 내보내며, 대부분의 변환기가 거부하는 팔레트 비트맵 레이어도 함께 처리합니다.
.ico 파일 안에 실제로 들어 있는 것
- 6바이트, 그다음 이미지마다 16바이트
- 헤더는 예약
00 00, 아이콘을 뜻하는01 00(02 00은 커서 파일), 그리고 2바이트 개수입니다. 각 디렉터리 엔트리는 너비, 높이, 팔레트 크기, 예약 바이트가 각각 1바이트씩이고, 이어서 2바이트 평면 수와 비트 심도, 마지막으로 페이로드의 길이와 위치를 담은 4바이트 필드 두 개가 옵니다. 여러 바이트를 쓰는 값은 전부 리틀 엔디언입니다. - 0은 256을 뜻하고 512는 표현할 수 없다
- 너비와 높이가 1바이트이므로 256은 0으로 인코딩할 수밖에 없고, 그보다 큰 값에는 인코딩 자체가 없습니다. 256px 레이어에 0 대신 255를 적는 것은 비슷한 근삿값이 아니라, 브라우저가 그리기를 거부하는 파일을 낳습니다. 512px 옵션을 제공하는 변환기는 자기 내용을 설명하지 못하는 엔트리를 쓰고 있는 셈입니다.
- 비압축 레이어는 정확히 40 + 너비 × 높이 × 4바이트에 마스크가 더해진다
- 마스크는 행마다
ceil(너비 ÷ 32) × 4바이트를 더합니다. 그래서 16px 레이어는 1,128바이트, 48px는 9,640바이트, 256px는 270,376바이트이며 그림이 무엇이든 달라지지 않습니다. 이 고정 비용 때문에 아무 관련 없는 세 사이트가 길이가 똑같은 파비콘을 배포할 수 있고, 이 페이지가 256px 레이어를 페이로드가 PNG일 때만 제공하는 이유이기도 합니다. - 비트맵 헤더는 높이를 두 배로 저장한다
- 비압축 레이어 안에서 높이 필드는 색상 비트맵과 투명 마스크를 겹쳐 쌓은 것을 가리키므로, 마스크가 아무 정보도 담지 않을 때조차 실제 높이의 두 배로 적습니다. 이를 틀리는 것은 이 포맷에서 가장 조용한 실패 중 하나입니다. 어떤 디코더는 빈 이미지를 내놓고, 어떤 디코더는 그림의 아래 절반을 내놓으며, 둘 다 오류를 알리지 않습니다.
- 평면 수, 비트 심도, 색상 수 필드는 잘해야 참고용
- 명세는 이 필드들을 정확히 규정하지만 실제 파일들은 이를 무시합니다. 마이크로소프트 자사 문서 사이트는 디렉터리가 평면 0개, 픽셀당 0비트라고 주장하면서 뒤에는 픽셀당 4비트 페이로드를 매단 파비콘을 제공하는데도 어디서나 잘 표시됩니다. 디코더는 디렉터리를 믿는 대신 PNG 시그니처나 비트맵 헤더 같은 페이로드 자체에서 실제 형식을 알아냅니다.
- ICO에는 RFC가 있었던 적이 없다
- 미디어 타입
image/vnd.microsoft.icon은 2003년 9월 IANA에 등록되었고, 그 등록이 인용하는 참고 문헌은 1995년 마이크로소프트 글 「Icons in Win32」입니다. ICO 명세로 널리 인용되는 RFC 2361은 사실 제목이 「WAVE and AVI Codec Registries」이며 이미지에 대해서는 한마디도 하지 않습니다.
favicon.ico 제대로 준비하기
- 웹용이라면 16, 32, 48만 담고 멈추기
- 이 세 조합은 1995년부터 권장되어 왔고 실제 파비콘에서 가장 자주 보이는 구성이기도 합니다. 크기를 더 넣는 것은 공짜가 아닙니다. 하나하나가 브라우저가 어느 것을 원하는지 알기도 전에 내려받을 수 있는 레이어입니다.
- 16px 레이어는 큰 그림을 줄이지 말고 따로 그리기
- 256px에서 잘 보이는 로고도 16px까지 내려오면 가는 선을 대개 잃습니다. 작은 크기가 중요하다면 형태를 줄이고 선을 굵게 해서 도안 자체를 단순화한 뒤, 그 단순화한 판을 별도 레이어로 담으십시오.
- link 요소를 쓰고 /favicon.ico는 대비책으로 남기기
- HTML 명세가 브라우저에 알려 주는 것은 아이콘 link가 없을 때에 한해 /favicon.ico를 가져와도 된다는 것뿐입니다. 믿을 수 있는 경로는 명시적인 link 요소이며, 루트 파일은 피드 리더, 크롤러처럼 여러분의 마크업을 파싱하지 않는 쪽을 위해 제 값을 합니다.
- 검색 결과가 중요하면 48px보다 큰 크기도 준비하기
- Google의 파비콘 지침은 최소 8px의 정사각형 이미지를 요구하고, 여러 표시 영역에서 버티도록 48px보다 크게 하기를 권합니다. PNG도 ICO만큼 쉽게 받아들이므로 그 큰 크기는 굳이 .ico 안에 있을 필요가 없습니다.
- 눈으로 보지만 말고 파일을 점검하기
- 브라우저에서 잘 그려지는 아이콘도 잘못되어 있을 수 있습니다. 어긋난 디렉터리 엔트리, 빠진 알파 채널, 읽히지 않는 레이어가 있어도 브라우저가 고른 그 한 장이 표시되는 것은 막히지 않습니다. 반대 방향 탭에서 파일을 열면 그 전부가 보입니다.
PNG ICO 변환 자주 묻는 질문
PNG를 ICO 파일로 어떻게 변환하나요?
이 페이지에 PNG를 끌어다 놓고 16, 32, 48px 선택을 그대로 둔 채 결과를 내려받으십시오. 모든 처리가 브라우저에서 이루어지므로 이미지는 업로드되지 않습니다. 명령줄에서 흔히 쓰는 대응 방법은
magick logo.png -define icon:auto-resize=48,32,16 favicon.ico입니다. 아이콘이 작은 크기에서 흐릿한 이유는 무엇인가요?
거의 언제나 파일에 큰 이미지 하나만 들어 있고 작은 표시는 전부 브라우저가 즉석에서 줄인 결과이기 때문입니다. 픽셀 격자가 줄어드는 순간 무손실 변환은 존재하지 않습니다. 가는 선과 세밀한 디테일은 리샘플링이 아무리 좋아도 24px 아래에서는 사라지므로, 화질을 결정하는 것은 어떤 크기를 담았는지이지 변환기가 아닙니다. 진짜 16px 레이어를 담으십시오. 로고가 복잡하다면 그 레이어만큼은 축소가 아니라 도안을 단순화해야 합니다.
안에 들어가는 이미지는 PNG가 좋나요, 비압축 BMP가 좋나요?
특별한 이유가 없다면 PNG입니다. 용량이 한 자릿수 배 작고 현재 모든 브라우저와 Vista 이후의 모든 Windows가 읽습니다. 그래도 현실에서는 비압축 비트맵이 여전히 더 흔한데, 주로 ImageMagick이 기본적으로 그쪽으로 변환하기 때문이며, 아주 오래된 소프트웨어를 상대할 때는 더 안전한 선택이기도 합니다. 이 페이지는 두 용량을 모두 보여 주므로 숫자로 결정할 수 있습니다.
512px 옵션이 없는 이유는 무엇인가요?
디렉터리가 각 변의 길이를 1바이트에 담기 때문에 표현할 수 있는 최댓값이 255이고, 0은 256을 뜻하도록 예약되어 있습니다. 512를 적을 방법이 없습니다. 이 옵션을 제공하는 변환기는 뒤에 오는 이미지를 설명하지 못하는 디렉터리 엔트리를 내놓게 되며, 일부 소프트웨어가 표시를 거부하는 아이콘을 얻기 딱 좋은 방법입니다.
투명 배경 PNG는 ICO로 변환해도 투명하게 남나요?
네. 알파 채널을 온전히 기록하고, 오래된 소프트웨어가 대신 읽는 1비트 마스크도 비워 두지 않고 알파에서 유도합니다. 그 마스크를 비워 두는 것이 바로 일부 도구에서 투명 배경이 검은 사각형으로 변하는 원인입니다. 반투명 픽셀은 알파가 절반 아래로 내려가면 마스크에서 투명으로 셈합니다. 마스크가 픽셀당 1비트뿐이라 이것이 유일하게 가능한 선택입니다.
SVG를 ICO로 변환할 수 있나요?
가능하며, 각 크기가 비트맵을 다시 샘플링하는 대신 도형의 기하에서 그려지므로 벡터 원본이 가장 좋은 입력입니다. 한 가지 주의할 점이 있습니다. 연결된 이미지, 원격 폰트, 가져오는 스타일시트처럼 SVG가 네트워크로 끌어오는 것은 변환 중에 차단되며 오류도 나지 않습니다. 이 페이지는 그런 참조를 점검해 경고해 줍니다.
사이트 루트에 favicon.ico가 여전히 필요한가요?
두는 편이 좋지만 더 이상 주된 경로는 아닙니다. HTML 명세는 브라우저가 /favicon.ico를 요청해도 된다고만, 그것도 페이지에 아이콘 link 요소가 없을 때만 말합니다. 브라우저가 먼저 쓰도록 안내된 것은 link 요소이며, 루트 파일은 피드 리더, 크롤러처럼 여러분의 HTML을 전혀 파싱하지 않는 쪽을 감당합니다.
Google 검색 결과에 ICO 파일이 필요한가요?
아니요. Google의 파비콘 문서는 BMP, GIF, ICO, PNG, JPEG, PPM, TIFF를 받아들이고, 최소 8px의 정사각형 이미지를 요구하며, 여러 표시 영역에서 제대로 보이도록 48px보다 크게 하기를 권합니다. 큼직한 PNG 한 장이면 충족됩니다. .ico는 그 밖의 모든 곳을 위한 것입니다.
브라우저로 .ico를 열면 크기가 하나만 보이는 이유는 무엇인가요?
img 요소가 줄 수 있는 것이 그뿐이기 때문입니다. 다중 크기 .ico를 브라우저에 넘기면 한 장을 고르는데 실제로는 가장 큰 것을 고르며, 나머지에는 손이 닿지 않습니다. 모든 레이어를 나열하려면 컨테이너를 직접 파싱해야 하고, 그것이 이 페이지의 ICO → PNG 탭이 하는 일입니다.
디렉터리와 이미지가 크기를 두고 엇갈리면 무슨 뜻인가요?
그 파일이 내부적으로 앞뒤가 맞지 않는다는 뜻이며, 디코더들은 정반대로 처리합니다. 어떤 디코더는 디렉터리를 믿어 결국 아무것도 그리지 않고, 어떤 디코더는 이미지 데이터를 믿어 제대로 렌더링합니다. 아이콘이 한 컴퓨터에서는 되고 다른 컴퓨터에서는 보이지 않는 전형적인 원인이라, 이 페이지는 파일을 열 때 이를 표시해 줍니다.
다른 변환기가 거부하는 ICO 파일도 열 수 있나요?
대체로 그렇습니다. 팔레트 비트맵으로 저장된 레이어, 즉 픽셀당 4비트나 8비트짜리는 잘 알려진 몇몇 파비콘이 여전히 쓰는데 많은 변환기가 아예 거부합니다. 망가진 레이어도 하나씩 처리하므로 읽히지 않는 크기가 하나 있어도 나머지를 내보내는 일은 멈추지 않습니다. 목록에는 Firefox가 버릴 내장 PNG 레이어도 표시됩니다. Firefox의 ICO 디코더는 8비트 RGB나 RGBA만 받아들이므로 팔레트나 그레이스케일 PNG는 거기서 사라집니다. Mozilla 자체 사이트도 바로 그 문제를 가진 아이콘을 배포한 적이 있습니다. 64px 레이어가 팔레트 PNG여서 Firefox 자신이 그것을 버리고, 나머지 레이어들만으로 아이콘이 겨우 보이는 상태를 유지합니다.
제 이미지가 어딘가로 업로드되나요?
아니요. 파일은 브라우저의 File API로 읽히고, 이 페이지의 canvas에 그려지며, 로컬에서 실행되는 JavaScript가 컨테이너로 포장합니다. 이미지를 어딘가로 실어 나르는 요청은 없으며, 개발자 도구의 네트워크 패널에서 직접 확인할 수 있습니다. 페이지를 불러온 뒤 인터넷 연결을 끊어도 오프라인 상태에서 그대로 변환됩니다.
관련 도구
모든 도구 보기 →진법 변환기 (Number Base Converter)
변환 도구
2진수, 16진수, 10진수, 8진수 및 임의 진법(2-36)을 즉시 변환합니다. 온라인에서 무료로 사용할 수 있으며 모든 처리는 브라우저에서 이루어집니다.
2의 보수 계산기 — 부호 있는 정수 인코딩 변환
변환 도구
부호 있는 정수를 넣으면 부호-절대값, 1의 보수, 2의 보수, 오프셋 바이너리를 4~64비트로 한 번에 계산합니다. 비트열이나 16진수로 역방향 조회도 지원합니다.
chmod 계산기 — 리눅스 파일 권한
변환 도구
리눅스 파일 권한을 8진수(755, 644)와 rwx 기호로 변환하는 온라인 chmod 계산기. 명령 생성과 777 위험 경고까지 브라우저에서 바로 처리합니다.
색상 변환기 — HEX, RGB, HSL, OKLCH
변환 도구
HEX, RGB, HSL, OKLCH, OKLAB, CMYK 등 9가지 색상 형식을 브라우저에서 즉시 변환합니다. 무료 온라인 도구, 가입 불필요.
HEX CMYK 변환기
변환 도구
HEX 색상을 CMYK로 변환합니다. 인쇄 시안용 sRGB 기반 근사. 무료 온라인 도구, 색상은 페이지를 벗어나지 않습니다.
HEX HSL 변환기
변환 도구
HEX 색상을 HSL로 변환합니다. 3자리, 6자리, 알파 포함 8자리 모두 지원. 무료 온라인 도구, 즉시 변환.