JPEG XL กลับมาใน Chrome แล้ว: ทำไมเคยถูกถอด และควรใช้ตอนนี้ไหม

JPEG XL คือฟอร์แมตรูปมาตรฐาน ISO/IEC 18181 ที่บีบได้ดีกว่า JPEG มี HDR, ภาพเคลื่อนไหว, progressive และแปลงไฟล์ JPEG เดิมแบบไม่เสียข้อมูลได้ Chrome เคยถอดออกไปในปี 2022 จนหลายคนคิดว่าจบแล้ว แต่ตุลาคม 2026 Chrome เอากลับมา บทความนี้เล่าว่าเกิดอะไรขึ้น ตอนนี้ใครรองรับ และควรเริ่มใช้แค่ไหน

ข้อมูลตรวจกับบล็อก Chrome for Developers, caniuse, MDN (Firefox 158) และ README ของ libjxl 0.12 ณ ตุลาคม 2026

ทำไม Chrome เคยถอด

Chrome มีตัวถอด JPEG XL หลัง flag ตั้งแต่ Chrome 91 (ต้องเปิดเองใน chrome://flags ผู้ใช้ทั่วไปไม่ได้ใช้) ปลายตุลาคม 2022 ทีม Chromium ประกาศถอดออกใน Chrome 110 เหตุผลที่เขียนไว้ใน bug tracker มีสามข้อ

1. flag ทดลองไม่ควรค้างไว้ตลอดไป
2. ทั้งวงการสนใจไม่พอ ที่จะทดลองต่อ
3. ประโยชน์ที่เพิ่มจากฟอร์แมตที่มีอยู่ (คือ AVIF และ WebP) ยังไม่พอจะเปิดเป็นค่าเริ่มต้น และการถอดช่วยลดงานดูแล

Chrome 110 ออก stable 7 กุมภาพันธ์ 2023 โดยไม่มี JPEG XL การตัดสินใจนี้ถูกค้านจากนักพัฒนาจำนวนมาก และเมื่อเบราว์เซอร์ที่มีส่วนแบ่งมากที่สุดไม่รองรับ เว็บส่วนใหญ่ก็ไม่มีเหตุผลจะทำไฟล์ .jxl

ทำไมกลับมา และ jxl-rs คืออะไร

บล็อก Chrome (6 ตุลาคม 2026) บอกว่าตัดสินใจจาก คำขอที่ต่อเนื่องของนักพัฒนาเว็บ JPEG XL เป็นหนึ่งในข้อเสนอยอดนิยมของ Interop 2026 และ Chrome เข้าร่วมงานสำรวจ JPEG XL ใน Interop 2026 เพื่อให้มีชุดทดสอบครอบฟีเจอร์ของฟอร์แมต

ส่วนที่น่าสนใจกว่าคือ ตัวถอดรหัส Chrome ไม่ได้เอา libjxl (C++) กลับมา แต่ใช้ jxl-rs ตัวถอดรหัสที่เขียนด้วย Rust ล้วน image decoder เป็นจุดที่โดนโจมตีบ่อย เพราะรับไฟล์จากเว็บไหนก็ได้แล้วต้อง parse รูปแบบที่ซับซ้อน บั๊กหน่วยความจำในโค้ด C/C++ ตรงนี้เคยกลายเป็นช่องโหว่ร้ายแรงในหลายเบราว์เซอร์ Rust ตัดปัญหากลุ่มนี้ตั้งแต่ภาษา ทีม Chrome เขียนว่าใช้ fuzzing และ AI code review และยังไม่พบบั๊ก memory safety ตลอดประวัติของโค้ดนี้

เรื่องนี้ไม่ได้เป็นแค่ข่าวฟอร์แมตรูป มันคือตัวอย่างที่ชัดว่าโค้ดที่ parse ข้อมูลจากคนแปลกหน้าควรเขียนด้วยภาษาที่ปลอดภัยด้านหน่วยความจำ

ใครรองรับ ณ ตุลาคม 2026

เบราว์เซอร์	สถานะ
Chrome desktop	155 ขึ้นไป (stable 6 ต.ค. 2026)
Chrome Android	156 ขึ้นไป
Firefox (desktop และ Android)	158 ขึ้นไป เปิดเป็นค่าเริ่มต้น (13 ต.ค. 2026)
Safari macOS / iOS	17 ขึ้นไป caniuse ระบุเป็น partial
Edge	ยังไม่รองรับ
Samsung Internet	ยังไม่รองรับ

caniuse ให้ตัวเลขผู้ใช้ทั่วโลก รองรับเต็ม 43.26% และบางส่วน 16.93% รวม 60.19% เทียบกับ AVIF ที่ราว 96% (บทความรูป responsiveเล่าไว้) ตัวเลข JPEG XL จะขึ้นเร็วในช่วงนี้ เพราะ Chrome และ Firefox อัปเดตตัวเองอัตโนมัติ

Firefox 158 ยังเพิ่ม image/jxl ใน Accept header ของคำขอรูปด้วย ค่าใหม่คือ image/avif,image/jxl,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5

JPEG XL เด่นตรงไหนเมื่อเทียบ AVIF

บล็อก Chrome อ้างว่า JPEG XL บีบได้ดีกว่า JPEG 30-50% และแนะนำให้ ลองทั้ง AVIF และ JPEG XL โดยบอกว่า JPEG XL ช่วยมากที่สุดกับงานคุณภาพสูงหรือ lossless

	AVIF	JPEG XL
รองรับ (caniuse ต.ค. 2026)	~96%	~60% (รวม partial)
รูปเว็บทั่วไป บีบแรง	เด่น	ใช้ได้
คุณภาพสูง / lossless	ใช้ได้	จุดแข็ง
แปลง JPEG เดิมแบบไม่เสียข้อมูล	ไม่มี	มี แปลงกลับได้ไฟล์เดิม
progressive (เห็นภาพหยาบก่อน)	ไม่มีแบบละเอียด	มีหลายระดับ
HDR	มี	มี

ข้อที่ไม่มีฟอร์แมตอื่นทำได้คือ lossless JPEG transcoding เว็บที่มีคลังรูป JPEG เก่าหลายหมื่นไฟล์ แปลงเป็น .jxl ได้เล็กลงโดยไม่มีพิกเซลไหนเปลี่ยน และถ้าวันหนึ่งต้องการ JPEG กลับ ก็ได้ไฟล์เดิมทุกไบต์

ลองกับรูปของเราเอง

ติดตั้ง libjxl (Debian/Ubuntu มีแพ็กเกจ libjxl-tools แต่เวอร์ชันใน repo อาจเก่า libjxl แนะนำ 0.12 ขึ้นไปเพราะมีแก้ช่องโหว่หลายจุด)

# Debian 13 / Ubuntu
sudo apt install libjxl-tools

# JPEG เดิม → JPEG XL แบบ lossless (ค่าเริ่มต้นของ cjxl เมื่อ input เป็น JPEG)
cjxl photo.jpg photo.jxl

# แปลงกลับ แล้วตรวจว่าตรงกับต้นฉบับทุกไบต์
djxl photo.jxl back.jpg
cmp photo.jpg back.jpg && echo "identical"

# จาก PNG ต้นฉบับ: lossy ด้วย distance (0 = lossless, ช่วงที่ใช้บ่อย 0.5-3)
cjxl hero.png hero.jxl -d 1.0
ls -l photo.jpg photo.jxl hero.png hero.jxl

ลดได้เท่าไรขึ้นกับรูป เราไม่ใส่ตัวเลขกลางให้ ให้รันกับรูปจริงสัก 20-30 ไฟล์แล้วดูผลรวม

ใส่ในหน้าเว็บด้วย picture

เบราว์เซอร์อ่าน <source> จากบนลงล่าง ตัวไหนมี type ที่ไม่รู้จักก็ข้าม จึงเพิ่ม JPEG XL ได้โดยไม่ทำให้ใครพัง

<picture>
  <source type="image/jxl"  srcset="/img/product-800.jxl 800w, /img/product-1600.jxl 1600w"
          sizes="(min-width: 800px) 800px, 100vw">
  <source type="image/avif" srcset="/img/product-800.avif 800w, /img/product-1600.avif 1600w"
          sizes="(min-width: 800px) 800px, 100vw">
  <img src="/img/product-800.jpg" alt="กระเป๋าหนังสีน้ำตาล มุมหน้า"
       width="800" height="800" loading="lazy">
</picture>

ลำดับ: ถ้ารูปนี้เป็นงานคุณภาพสูง (ภาพสินค้าที่ซูมได้ งานถ่ายภาพ) วาง JPEG XL บนสุด ถ้าเป็นรูปทั่วไปที่บีบแรง วาง AVIF บนสุดไปเลยก็ได้ แล้วไม่ต้องมี JPEG XL

ตัวอย่างคำนวณ: ต้นทุนของฟอร์แมตที่สาม

สมมติรูปหนึ่งรูปทำ 4 ความกว้าง (480, 800, 1200, 1600)

• เดิม AVIF + JPEG = 4 × 2 = 8 ไฟล์ต่อรูป
• เพิ่ม JPEG XL = 4 × 3 = 12 ไฟล์ต่อรูป เพิ่มขึ้น (12 − 8) ÷ 8 = 50%
• คลัง 2,000 รูป: จาก 16,000 เป็น 24,000 ไฟล์ เวลา build และพื้นที่ storage/CDN โตตามสัดส่วนนี้คร่าว ๆ

ส่วนที่ได้คืน ใช้ตัวเลขสมมติให้เห็นวิธีคิด (แทนด้วยค่าที่วัดเองจากหัวข้อก่อน) สมมติรูปสินค้าหนึ่งรูปเป็น AVIF 120 KB และ JPEG XL 100 KB ผู้ชมที่ได้ JPEG XL ประหยัด 20 KB ต่อรูป หน้าสินค้ามี 10 รูป = 200 KB ต่อหน้า ถ้าผู้ชม 60% รองรับ JPEG XL และมีเปิดหน้า 50,000 ครั้งต่อเดือน

• 50,000 × 0.60 × 200 KB = 6,000,000 KB ≈ 6 GB ต่อเดือน

ถ้า 6 GB ต่อเดือนเทียบกับไฟล์เพิ่ม 50% แล้วคุ้ม ก็ทำ ถ้าส่วนต่างที่วัดจริงเล็กกว่านี้มาก เก็บ AVIF อย่างเดียวไว้ก่อน

ข้อผิดพลาดที่เจอบ่อย

• เสิร์ฟ .jxl ใน <img> ตรง ๆ Edge และเบราว์เซอร์เก่าจะเห็นรูปแตก ต้องอยู่ใน <picture> ที่มีทางสำรองเสมอ
• เซิร์ฟเวอร์ส่ง Content-Type ผิด nginx รุ่นเก่าอาจไม่มี jxl ใน mime.types เช็คด้วย curl -sI https://example.com/img/a.jxl ว่าได้ image/jxl ถ้าไม่ใช่ เพิ่ม image/jxl jxl; ใน types
• ทำ content negotiation แต่ลืม Vary: Accept CDN จะ cache ไฟล์ .jxl แล้วส่งให้เบราว์เซอร์ที่เปิดไม่ได้
• แปลง JPEG แบบ lossy ซ้ำ ถ้าต้นทางเป็น JPEG ให้ใช้การแปลงแบบ lossless (ค่าเริ่มต้น) การบีบ lossy ทับรูปที่ lossy อยู่แล้วเสียคุณภาพสองรอบ
• ใช้ libjxl เก่า บน server ที่รับรูปจากผู้ใช้ เวอร์ชันเก่ามีช่องโหว่ที่แก้แล้วใน 0.12

ใช้ JPEG XL ตอนนี้ได้ ถ้าอยู่ใน picture ที่มีทางสำรอง แต่ AVIF ยังเป็นตัวหลักของรูปเว็บทั่วไป

แหล่งอ้างอิง

• Shipping JPEG XL in Chrome — Chrome for Developers
• JPEG XL (JXL) image format — caniuse
• Firefox 158 release notes for developers — MDN
• JPEG XL overview — jpeg.org
• libjxl reference implementation — GitHub
• Google drops forthcoming version of JPEG from Chromium — The Register