Công cụ Nén Hình Ảnh Trực Tuyến Miễn Phí

Cách hoạt động

1. Chọn hoặc thả một hoặc nhiều hình ảnh ở trên.
2. Điều chỉnh thanh trượt chất lượng (thấp hơn = tệp nhỏ hơn, nén nhiều hơn).
3. Hình ảnh được nén trong trình duyệt của bạn · không có gì được tải lên.
4. Tải xuống hình ảnh đã nén từng ảnh hoặc tất cả cùng một lúc.

Tại sao nên nén hình ảnh?

Hình ảnh lớn làm chậm trang web, tăng tỷ lệ thoát và ảnh hưởng xấu đến xếp hạng Google của bạn. Nén hình ảnh giúp giảm kích thước tệp 50-80% với chất lượng nhìn thấy được giảm tối thiểu. Điều này rất cần thiết cho các nhà phát triển web, blogger, cửa hàng thương mại điện tử và bất kỳ ai xuất bản nội dung trực tuyến. Hình ảnh nhỏ hơn cũng tiết kiệm băng thông trên thiết bị di động và cải thiện điểm Core Web Vitals.

Nén hình ảnh thực sự có nghĩa là gì

Nén hình ảnh bao gồm hai thao tác về cơ bản khác nhau cùng tên. Nén có tổn thất, được sử dụng bởi JPEG và WebP có tổn thất, loại bỏ dữ liệu hình ảnh mà mắt người khó nhận thấy (các sắc thái tinh tế trong chi tiết bóng, nhiễu tần số cao, chroma subsampling cho tỷ lệ màu-vs-độ sáng được điều chỉnh cho thị giác người). Đầu ra nhỏ hơn đầu vào nhưng không thể được tái tạo từng bit. Nén không tổn thất, được sử dụng bởi PNG, GIF, TIFF-LZW và WebP không tổn thất, mã hóa dữ liệu pixel chính xác một cách gọn hơn bằng cách sử dụng các thuật toán như DEFLATE (LZ77 + Huffman). Đầu ra nhỏ hơn, và việc giải nén tái tạo bản gốc từng byte. Cái nào đúng phụ thuộc vào hình ảnh: ảnh chấp nhận có tổn thất rất tốt vì nội dung của chúng đầy kết cấu mà mắt không thể theo dõi ở cấp pixel; logo, ảnh chụp màn hình và đồ họa với chuyển đổi màu sắc nét đòi hỏi không tổn thất vì mỗi pixel đều có chủ ý.

Cài đặt chất lượng trong trình nén JPEG (thanh trượt trên công cụ này, 10-100%) kiểm soát các bảng lượng tử hóa được áp dụng sau bước DCT. Ở chất lượng 100, các bảng hầu như không làm tròn bất kỳ hệ số tần số nào; ở chất lượng 50, chúng làm tròn một cách tích cực. Chất lượng cao hơn có nghĩa là các tệp lớn hơn với chi tiết tinh hơn; chất lượng thấp hơn có nghĩa là các tệp nhỏ hơn với hiện vật khối có thể nhìn thấy ở các vùng phẳng. Mặc định 60% nằm ở điểm ngọt cho việc sử dụng web: thường là giảm kích thước tệp 50-80% mà không có sự thay đổi có thể nhận thấy trên màn hình điển hình. Đối với công việc in hoặc hiển thị lớn, đẩy lên 80-90%. Đối với hình thu nhỏ hoặc phiên bản thân thiện với email, 30-50% là ổn.

Đối với PNG, thanh trượt chất lượng không áp dụng theo nghĩa thông thường vì PNG luôn không tổn thất. Điều mà công cụ này thực sự làm với các đầu vào PNG là chạy một pass DEFLATE mạnh hơn so với hầu hết phần mềm tác giả (Photoshop, Affinity, Sketch) sẵn lòng làm theo mặc định; điều đó thường nén 5-25% kích thước tệp với không có thay đổi pixel nào. Dropdown Định dạng cũng cho phép bạn chuyển đổi PNG sang JPEG hoặc WebP, đổi không tổn thất lấy một tệp nhỏ hơn nhiều nhưng mất tính trong suốt cho đầu ra JPEG và (cho nội dung ảnh) đảm bảo không tổn thất cho WebP. Tùy chọn Chiều rộng Tối đa thay đổi kích thước hình ảnh trong khi nén: một bức ảnh rộng 4000 pixel được giảm xuống 1920 pixel tiết kiệm 75% số pixel thô trước khi bất kỳ kompresion nào thậm chí chạy, vì vậy nó chồng lên với việc giảm chất lượng.

Công cụ này hoạt động bên dưới như thế nào

Động cơ nén là browser-image-compression bởi Donald Wong (GitHub: Donaldcwl/browser-image-compression, giấy phép MIT). Đó là một thư viện JavaScript thuần túy, khoảng 95 KB được minify, bao bọc ba primitive trình duyệt: File API để đọc byte, Canvas API (hoặc OffscreenCanvas khi có sẵn) để giải mã, thay đổi kích thước và mã hóa lại các hình ảnh JPEG/WebP, và UZIP (một thư viện DEFLATE nhỏ) để xử lý PNG mà không cần đi qua Canvas. Khi bạn thả một hình ảnh, trình duyệt giao byte cho thư viện; thư viện chọn đường đi dựa trên định dạng đầu vào và đầu ra được yêu cầu.

Đối với các đầu vào JPEG và WebP, đường đi là giải mã-thành-canvas, tùy chọn thay đổi kích thước thành Chiều rộng Tối đa được cấu hình, sau đó gọi canvas.toBlob(mimeType, quality/100). Bộ mã hóa JPEG hoặc WebP tích hợp trong trình duyệt thực hiện lượng tử hóa và mã hóa Huffman thực tế. Chất lượng là giá trị thanh trượt của bạn chia cho 100, được truyền dưới dạng tham số thứ hai. Đối với các đầu vào PNG được giữ là PNG, thư viện hoàn toàn bỏ qua Canvas (một vòng tròn Canvas sẽ không cần thiết re-rasterize dữ liệu không tổn thất) và thay vào đó chạy UZIP trên các đoạn IDAT của tệp PNG trực tiếp, với nỗ lực nén tối đa. Đây là lý do tại sao nén PNG-to-PNG ở đây thực sự là không tổn thất: dữ liệu pixel không bao giờ được giải mã và mã hóa lại, chỉ có lớp bọc DEFLATE được thắt chặt.

Khi OffscreenCanvas được hỗ trợ (Chrome, Edge, Safari, Firefox hiện đại), công việc giải mã-thay đổi kích thước-mã hóa nặng chạy bên trong một Web Worker, giữ luồng UI chính phản hồi. Bạn có thể thả một loạt 20 bức ảnh và tiếp tục cuộn trang trong khi mỗi bức được xử lý. Trên các trình duyệt cũ hơn, thư viện rơi xuống luồng chính, vẫn hoạt động nhưng chặn trang trong các công việc lớn. Toàn bộ pipeline chạy bên trong tab của bạn. Thư viện được tải một lần từ CDN (khoảng 95 KB được minify) trong lần truy cập đầu tiên, được cache sau đó. Không có nội dung tệp nào rời khỏi trình duyệt. Mở tab Network trong DevTools trong khi bạn nén một loạt và bạn sẽ thấy lần fetch thư viện một lần nhưng không có gì khác.

Lịch sử ngắn về các định dạng nén hình ảnh

• DCT, 1972-1974. Nasir Ahmed đề xuất discrete cosine transform như một phương pháp nén hình ảnh vào năm 1972; thuật toán chính thức được xuất bản với T. Natarajan và K. R. Rao vào năm 1974. Một biến đổi toán học duy nhất này nằm dưới mọi tệp JPEG, MPEG và video H.26x trên thế giới ngày nay.
• JPEG, 1992. Joint Photographic Experts Group (thành lập 1986) đã chuẩn hóa JPEG là ITU-T T.81 / ISO/IEC 10918-1 vào năm 1992. Khối DCT 8x8, màu YCbCr với chroma subsampling tùy chọn, các bảng lượng tử hóa được điều chỉnh cho thị giác con người. Định dạng đã làm cho web giàu ảnh có thể.
• PNG, 1996. Được tạo tại IETF như RFC 2083 để thay thế GIF sau khi các tuyên bố bằng sáng chế LZW của Unisys đe dọa web mở. Nén DEFLATE (LZ77 + Huffman), luôn không tổn thất, trong suốt alpha đầy đủ, không có gánh nặng bằng sáng chế. Đặc tả 3rd Edition (W3C, 2023) đã thêm HDR, hoạt ảnh APNG và metadata EXIF chính thức.
• WebP, 2010. Google phát hành WebP như một định dạng hình ảnh tĩnh dựa trên mã hóa intra-frame của codec video VP8. WebP có tổn thất chạy nhỏ hơn 25-34% so với JPEG ở chất lượng hình ảnh tương đương; WebP không tổn thất chạy nhỏ hơn khoảng 26% so với PNG. Việc áp dụng mất một thập kỷ; đến năm 2026, hơn 96% trình duyệt trên toàn thế giới hỗ trợ nó.
• AVIF, 2019. Alliance for Open Media đã phát hành AVIF như biến thể hình ảnh tĩnh của codec video AV1. Khoảng 50% nhỏ hơn JPEG ở chất lượng tương đương. Hỗ trợ trình duyệt hiện nay là 95%+ nhưng hỗ trợ encoder trong các công cụ tác giả hàng ngày (Photoshop, Word, Slack) chậm lại. Squoosh và ImageMagick có thể tạo AVIF hôm nay; hầu hết các máy ảnh và điện thoại không thể.
• HEIC, 2017. Apple đã áp dụng HEIF/HEIC dựa trên H.265 làm định dạng ảnh mặc định của iPhone. Khoảng một nửa kích thước của JPEG tương đương. Bị gánh nặng tiền bản quyền, vì vậy hiếm khi được phục vụ trên web mở. Hầu hết các trình tải lên trực tuyến (bao gồm công cụ này) chỉ chấp nhận HEIC sau khi chuyển đổi máy tính sang JPEG; chuyển đổi đó là quy trình hàng ngày để gửi ảnh điện thoại đến người nhận không phải Apple.

Định dạng được hỗ trợ

• JPEG · Tốt nhất cho ảnh chụp và hình ảnh phức tạp. Nén mất dữ liệu với chất lượng có thể điều chỉnh.
• PNG · Tốt nhất cho đồ họa, logo và hình ảnh có nền trong suốt.
• WebP · Định dạng hiện đại của Google cung cấp tệp nhỏ hơn JPEG/PNG với chất lượng tương đương.

Quy trình nén thế giới thực

• Hình ảnh blog và trang web. Một JPEG 2 MB trực tiếp từ camera điện thoại so với một JPEG nén 250 KB: giống hệt với mắt người trên màn hình điển hình, nhưng tệp nhỏ hơn tải nhanh hơn khoảng 8 lần. Điểm Core Web Vitals (LCP) cải thiện trực tiếp. Hầu hết các trang với nhiều ảnh thấy lợi ích hiệu suất Lighthouse lớn nhất từ nén hình ảnh, không phải từ tối ưu hóa JavaScript hay CSS.
• Tải lên mạng xã hội. Instagram, Twitter, Facebook, LinkedIn đều nén lại hình ảnh khi tải lên bằng cách sử dụng thuật toán riêng của họ. Việc nén trước cho bạn quyền kiểm soát những gì bị hy sinh; tải lên ảnh thô có nghĩa là nền tảng đưa ra những lựa chọn đó cho bạn, thường với sự suy giảm có thể nhìn thấy.
• Tệp đính kèm email. Hầu hết các nhà cung cấp giới hạn các tệp đính kèm ở 25 MB mỗi tin nhắn (Gmail, Outlook, Apple Mail). Nén một thư mục ảnh từ ~50 MB xuống ~10 MB cho phép bạn gửi mọi thứ trong một email thay vì chia thành nhiều lần gửi hoặc chuyển sang liên kết chia sẻ đám mây.
• Ảnh sản phẩm thương mại điện tử. Các danh mục sản phẩm với hàng trăm hoặc hàng nghìn ảnh thấy các hóa đơn băng thông CDN lớn và tải trang chậm. Nén toàn bộ thư viện cắt cả hai. Người bán Shopify, Etsy và Amazon thường nén trước khi tải lên để giảm chi phí lưu trữ và cải thiện thứ hạng tìm kiếm.
• Danh mục đầu tư nhiều ảnh chụp màn hình. Danh mục đầu tư thiết kế UI nặng PNG vì ảnh chụp màn hình có chuyển đổi màu sắc nét nơi các hiện vật JPEG sẽ có thể nhìn thấy. PNG-to-PNG qua DEFLATE chặt chẽ hơn thường tiết kiệm 10-20% với không có thay đổi pixel nào, hữu ích cho các trang danh mục đầu tư của nhà thiết kế cần duy trì nhanh mà không hy sinh chất lượng kết xuất.
• Giảm kích thước lưu trữ. Một bức ảnh 12 megapixel từ điện thoại là quá mức cho một album chia sẻ gia đình mà chỉ được xem trên màn hình. Thay đổi kích thước thành 4 megapixel ở 80% chất lượng: kết quả trông giống hệt trên mọi thiết bị sẽ thấy nó, và kho lưu trữ giảm xuống một phần năm kích thước ban đầu. Các bản gốc vẫn an toàn trên đĩa nguồn; các phiên bản nén đi đến chia sẻ hoặc sao lưu.

Cạm bẫy phổ biến và ý nghĩa của chúng

• Nén lại JPEG nhiều lần làm thoái hóa nó. Mỗi lần lưu JPEG chạy lại bước lượng tử hóa DCT, mất chi tiết mà bạn không bao giờ có thể phục hồi. Các tổn thất tinh tế ở pass đầu tiên và rõ ràng ở pass thứ ba hoặc thứ tư. Luôn nén từ nguồn chất lượng cao nhất bạn có (tệp camera gốc, xuất từ công cụ thiết kế của bạn), không phải từ một JPEG đã nén trước đó mà bạn đã lưu vào tuần trước. Nếu bạn cần thực hiện các điều chỉnh, giữ một bản sao master ở PNG hoặc TIFF.
• PNG-sang-JPEG làm mất tính trong suốt. JPEG đơn giản là không có kênh alpha trong đặc tả định dạng. Bất kỳ pixel trong suốt nào trở thành trắng đặc (hoặc bất cứ thứ gì encoder của bạn thay thế) khi bạn chuyển PNG sang JPEG. Đối với logo, biểu tượng, ảnh chụp màn hình có nền trong suốt hoặc bất kỳ đồ họa nào có kênh alpha, hãy ở lại trong PNG hoặc chuyển sang WebP, cả hai đều bảo tồn tính trong suốt.
• JPEG-sang-PNG làm cho tệp lớn hơn. Nén DEFLATE của PNG rất tốt ở các gradient mịn và các vùng đặc lớn, kém ở các mẫu nhiễu tần số cao mà nén JPEG để lại. Chuyển đổi JPEG sang PNG thường nhân đôi hoặc nhân ba kích thước tệp mà không tăng chất lượng. Nếu bạn cần không tổn thất từ một JPEG, bạn đã quá muộn: thông tin ban đầu đã biến mất. Việc chuyển đổi chỉ có ý nghĩa nếu bạn đặc biệt cần tính trong suốt của PNG hoặc một công cụ không chấp nhận JPEG.
• Metadata EXIF bị loại bỏ theo mặc định. Thư viện browser-image-compression mặc định loại bỏ metadata EXIF (thông tin camera, tọa độ GPS, ngày chụp, hồ sơ màu ICC) trong khi nén lại. Đối với sử dụng web đó thường là một tính năng (tọa độ GPS rò rỉ là một vấn đề riêng tư thực sự). Đối với các nhiếp ảnh gia lưu trữ với metadata còn nguyên vẹn, công cụ này không phù hợp; sử dụng một bộ nén máy tính như ImageOptim hoặc jpegtran với cờ rõ ràng preserve metadata.
• Hồ sơ màu có thể không tồn tại. Một hồ sơ màu ICC nhúng (sRGB, Adobe RGB, ProPhoto) cho hiển thị biết cách diễn giải các giá trị pixel. Mã hóa lại dựa trên Canvas có thể bỏ qua hồ sơ nhúng và gắn thẻ đầu ra là sRGB. Đối với sử dụng màn hình thông thường điều này ổn vì hầu như mọi thứ đều là sRGB. Đối với công việc chuẩn bị in, chuẩn bị ảnh quản lý màu hoặc đầu ra wide-gamut, hãy sử dụng một công cụ nhận biết màu (Export As của Photoshop, Affinity, RawTherapee) bảo tồn rõ ràng dữ liệu hồ sơ.
• Hình ảnh rất lớn có thể làm sập một tab trình duyệt di động. Giải mã hình ảnh vào Canvas cần RAM tỷ lệ thuận với kích thước của nó: một bức ảnh 24 megapixel (6000x4000 pixel) cần khoảng 96 MB chỉ cho bộ đệm pixel RGBA, cộng với bộ nhớ làm việc cho encoder. Các thiết bị di động với RAM 4 GB có thể bị OS chấm dứt tab trước khi encoding hoàn thành. Thay đổi kích thước đầu vào hoặc sử dụng trình duyệt máy tính cho các bức ảnh rất lớn.

Quyền riêng tư: hình ảnh ở lại trên thiết bị của bạn

Mọi bộ nén hình ảnh đám mây (TinyPNG, Compressor.io, Optimizilla, các công cụ hình ảnh của Smallpdf, endpoint compress của Pixlr, hàng tá dịch vụ nén hình ảnh trực tuyến) tải lên tệp của bạn lên máy chủ của nhà điều hành, chạy thuật toán nén của họ và trả về hình ảnh nhỏ hơn dưới dạng tải xuống. Tác động về quyền riêng tư không tầm thường vì ảnh thường xuyên chứa nội dung có thể nhận dạng: khuôn mặt, địa chỉ có thể nhìn thấy trong nền, ảnh chụp màn hình của UI nội bộ hoặc tài liệu bí mật, ảnh trẻ em, ảnh được chụp trong không gian riêng tư. Hầu hết các nhà điều hành xuất bản các chính sách quyền riêng tư cam kết xóa các tải lên trong vòng một hoặc hai giờ và mã hóa khi truyền, và các nhà lớn hơn (TinyPNG, Smallpdf) giữ chứng nhận ISO/IEC 27001. Họ có lý do thương mại mạnh mẽ để tôn trọng các chính sách đó. Nhưng đã xóa trong vòng một giờ không phải là không bao giờ thấy. Trong giờ đó nội dung hình ảnh nằm trong cơ sở hạ tầng của nhà điều hành, có thể truy cập bởi bất kỳ quy trình hoặc người nào có quyền truy cập thích hợp, và hiển thị trong nhật ký và sao lưu theo bất kỳ chính sách lưu giữ nào áp dụng.

Bộ nén này không bao giờ tải lên bất cứ thứ gì. Thư viện browser-image-compression chạy hoàn toàn trong tab của bạn; byte hình ảnh được đọc bởi File API, được xử lý trong JavaScript (hoặc trong Web Worker nếu OffscreenCanvas có sẵn), và đầu ra nén được trả về cùng tab dưới dạng Blob có thể tải xuống. Bạn có thể xác minh không có tải lên bằng cách mở các công cụ dành cho nhà phát triển của trình duyệt vào tab Network trước khi nén một loạt: không có yêu cầu nào kích hoạt bao gồm nội dung hình ảnh của bạn. Lưu lượng mạng duy nhất là fetch thư viện một lần (~95 KB) từ CDN trong lần truy cập đầu tiên, sau đó thư viện được cache. Chuyển trình duyệt sang chế độ máy bay sau khi tải trang và bộ nén tiếp tục hoạt động trên các tệp cục bộ. Đối với ảnh có bất cứ điều gì nhạy cảm (khuôn mặt, vị trí, ảnh chụp màn hình nội bộ), giao dịch phía trình duyệt rõ ràng đáng để thực hiện.

Khi một công cụ khác là lựa chọn đúng

• Xử lý hàng loạt 500+ hình ảnh trong một pipeline được script hóa. Sử dụng sharp trong Node.js (thư viện hình ảnh phía máy chủ chuẩn), ImageMagick hoặc GraphicsMagick trên dòng lệnh, hoặc Pillow trong Python. Các công cụ này xử lý hàng nghìn tệp mà không có giới hạn bộ nhớ trình duyệt và chạy từ các công việc CI, hook triển khai hoặc tác vụ cron.
• Bảo đảm không tổn thất nghiêm ngặt với sự bằng nhau bit có thể xác minh. Đối với PNG-sang-PNG, công cụ này thực sự không tổn thất vì UZIP không chạm vào dữ liệu pixel. Đối với các quy trình yêu cầu xác minh mật mã (hình ảnh y tế, bằng chứng pháp lý), hãy sử dụng một công cụ máy tính như ImageMagick với `-define png:compression-level=9` rõ ràng và xác minh SHA-256 của dữ liệu pixel được giải mã.
• Bảo tồn hồ sơ màu cấp in. Adobe Photoshop, Affinity Photo, hoặc RawTherapee cho công việc chuẩn bị in với bảo tồn hồ sơ ICC, soft-proofing và đầu ra CMYK. Nén dựa trên trình duyệt không thể đảm bảo các quy trình quản lý màu vì Canvas hoạt động trong sRGB và có thể loại bỏ dữ liệu hồ sơ được nhúng.
• Đầu ra AVIF cho nén thế hệ tiếp theo. browser-image-compression không xuất AVIF tính đến năm 2026. Để mã hóa AVIF trong trình duyệt, sử dụng Squoosh (cũng Google, cũng phía client); cho AVIF dòng lệnh, sử dụng avifenc từ libavif. AVIF tạo ra các tệp khoảng 50% nhỏ hơn JPEG ở chất lượng tương đương, nhưng encoder đắt về mặt tính toán (chậm hơn mã hóa JPEG 10 lần).

Câu hỏi thường gặp

Việc nén có làm giảm chất lượng hình ảnh không?

Ở mức chất lượng mặc định 60%, hầu hết các hình ảnh trông gần giống với bản gốc trong khi nhỏ hơn 50-80%. Điều chỉnh thanh trượt để tìm sự cân bằng phù hợp với nhu cầu của bạn.

Có giới hạn kích thước tệp không?

Mỗi hình ảnh có thể lên tới 50 MB. Vì quá trình xử lý diễn ra trong trình duyệt của bạn, các tệp rất lớn có thể mất một chút thời gian tùy thuộc vào thiết bị của bạn.

Hình ảnh của tôi có được tải lên máy chủ không?

Không. Tất cả quá trình nén diễn ra cục bộ trong trình duyệt của bạn. Hình ảnh của bạn không bao giờ rời khỏi thiết bị, giúp việc này hoàn toàn riêng tư và an toàn.

Tôi nên sử dụng cài đặt chất lượng nào?

Cho sử dụng trên web, 60-70% là lý tưởng. Cho in ấn hoặc danh mục đầu tư, hãy thử 80-90%. Cho nén tối đa (hình thu nhỏ, email), 30-50% hoạt động tốt.

Các câu hỏi thường gặp khác

Tại sao đầu ra PNG của tôi chỉ nhỏ hơn một chút so với bản gốc?

PNG là không tổn thất. Khoản tiết kiệm hoàn toàn đến từ việc tìm ra một nén DEFLATE chặt chẽ hơn của cùng một dữ liệu pixel, thường tiết kiệm 5-25% so với những gì một công cụ tác giả (Photoshop, Sketch, Figma) viết theo mặc định. Nếu PNG của bạn đã được tối ưu hóa tốt, không còn nhiều khoảng trống. Để có được sự giảm bổ sung có ý nghĩa, hoặc chuyển sang WebP (giữ trong suốt và thường nhỏ hơn PNG 25%) hoặc chấp nhận một số mất mát bằng cách chuyển sang JPEG (có thể nhỏ hơn nhiều nhưng làm rơi tính trong suốt).

Công cụ này có hoạt động ngoại tuyến không?

Sau lần truy cập đầu tiên, có. Thư viện browser-image-compression (khoảng 95 KB được minify) được cache bởi trình duyệt khi tải lần đầu. Các lần truy cập tiếp theo đến bộ nén hoạt động hoàn toàn ngoại tuyến, miễn là cache trình duyệt chưa được xóa trong thời gian đó. Bạn có thể xác minh bằng cách bật chế độ máy bay sau khi mở trang một lần và nén một hình ảnh cục bộ.

Dữ liệu EXIF của tôi (camera, GPS, ngày chụp) có được giữ nguyên không?

Không, metadata EXIF bị loại bỏ trong quá trình nén theo mặc định. Đối với chia sẻ web điều này thường là mong muốn (tọa độ GPS và số sê-ri camera không nên rò rỉ), nhưng đối với các nhiếp ảnh gia lưu trữ với metadata còn nguyên vẹn, công cụ này không phù hợp. Sử dụng một bộ nén có nhận biết EXIF của máy tính như ImageOptim (macOS) hoặc jpegtran với tùy chọn `-copy all` để bảo tồn metadata.

Sự khác biệt giữa thay đổi kích thước Chiều rộng Tối đa và giảm chất lượng là gì?

Thay đổi kích thước thay đổi các kích thước pixel của hình ảnh: một bức ảnh 4000x3000 được thay đổi kích thước thành 1920x1440 có ít hơn 75% pixel để mã hóa, cắt kích thước tệp trước khi bất kỳ kompresion nào thậm chí chạy. Giảm chất lượng (thanh trượt) kiểm soát mức độ tích cực mà bộ mã hóa JPEG hoặc WebP làm tròn các hệ số DCT của nó, làm cho dữ liệu được mã hóa nhỏ hơn trên mỗi pixel. Hai cái này chồng lên: thay đổi kích thước trước để giảm tổng số pixel, sau đó giảm chất lượng những gì còn lại. Đối với một quy trình điển hình làm cho điều này thân thiện với web, đặt chiều rộng tối đa 1920, chất lượng 70, và đầu ra khoảng 10-15% so với kích thước ban đầu.

Tôi có thể nén hình ảnh HEIC từ iPhone của mình không?

Hỗ trợ trình duyệt để giải mã HEIC bị giới hạn (Safari trên các thiết bị Apple làm điều đó; Chrome và Firefox không). Trên các trình duyệt không phải Apple, công cụ này sẽ từ chối các tệp HEIC. Quy trình cho ảnh iPhone là hoặc thay đổi cài đặt iPhone (Camera → Định dạng → Tương thích Nhất) để lưu JPEG trực tiếp, hoặc chuyển đổi HEIC sang JPEG một lần trên Mac hoặc với một công cụ chuyên dụng, sau đó chạy các JPEG đó qua bộ nén này. Bảng Chia sẻ qua iCloud thường chuyển đổi sang JPEG tự động khi chia sẻ với những người nhận không phải Apple.

Có một desktop hoặc dòng lệnh tương đương không?

Vài cái. Đối với tự động hóa hàng loạt, sharp trong Node.js là thư viện phía máy chủ tiêu chuẩn và tạo ra đầu ra gần như giống hệt. ImageMagick (magick input.jpg -quality 70 output.jpg) và GraphicsMagick xử lý các tệp khổng lồ và chạy từ bất kỳ shell nào. jpegoptim và optipng là các bộ mã hóa lại JPEG và PNG chuyên dụng thường ép thêm vài phần trăm so với các công cụ chung. Đối với công việc tương tác đơn lẻ như công cụ này nhưng với nhiều điều khiển hơn, Squoosh (Google Chrome Labs, cũng hoàn toàn phía client) hỗ trợ một loạt các định dạng rộng hơn bao gồm AVIF.

Công cụ liên quan