Bộ chuyển đổi hình ảnh hàng loạt miễn phí

Chuyển đổi nhiều hình ảnh cùng một lúc giữa PNG, JPG và WebP. Điều chỉnh chất lượng, so sánh kích thước tệp và tải xuống tất cả ngay lập tức.

Dữ liệu của bạn không bao giờ rời khỏi thiết bị của bạn
Thả hình ảnh vào đây hoặc nhấp để duyệt (JPEG, PNG, WebP, GIF, BMP, TIFF)

Đang xử lý…

Về việc chuyển đổi định dạng hình ảnh

Mỗi định dạng hình ảnh có công dụng riêng. PNG là không mất dữ liệu, lý tưởng cho đồ họa; JPG hoàn hảo cho ảnh và cung cấp các tệp nhỏ hơn; và WebP cung cấp khả năng nén hiện đại với chất lượng cao. Chuyển đổi hàng loạt tiết kiệm thời gian khi xử lý nhiều tệp.

JPEG (1992), định dạng của nhiếp ảnh

Joint Photographic Experts Group được lập tháng 11 năm 1986 tại Parsippany, New Jersey, với thành viên rút từ ISO TC97 SC2/WG8 và nhóm CCITT SGVIII. Sau sáu năm làm việc của ủy ban, văn bản CCITT Recommendation T.81 được phê duyệt ngày 18 tháng 9 năm 1992, cùng văn bản được công bố là International Standard ISO/IEC 10918-1 năm 1994. Lần công bố kép này là khoảnh khắc JPEG trở thành định dạng nhiếp ảnh của thế giới. Cốt lõi toán học là phép biến đổi cosin rời rạc áp dụng lên các khối 8×8 pixel: mỗi khối được phân tích thành tổng các sóng cosin, các thành phần tần số cao mà thị giác người ít nhạy nhất bị lượng tử hóa mạnh hơn các thành phần tần số thấp mà mắt nhận ra trước. Nút "chất lượng" phía người dùng đúng là cái đó, một hệ số nhân lên bảng lượng tử hóa. Chất lượng cao hơn nghĩa là số chia nhỏ hơn, độ chính xác cao hơn, tệp lớn hơn. Chất lượng thấp hơn nghĩa là nhiều số 0 sau lượng tử hóa, mã hóa entropy tốt hơn và tệp nhỏ hơn với cái giá là khối và artifact "ringing" thấy được. JPEG mất mát theo thiết kế: không có cài đặt chất lượng nào để vòng tròn JPEG giống hệt đầu vào về toán học. Cho ảnh chụp cảnh tự nhiên, mặt người, phong cảnh, đồ ăn, bất cứ gì có dải mượt và sắc tố liên tục, điều đó không quan trọng; mất mát sống dưới ngưỡng nhạy của thị giác người và tệp chiếm một phần nhỏ của kích thước mà định dạng không-mất-mát sẽ tạo ra. Cho đồ họa có cạnh sắc, văn bản, line art hoặc vùng màu phẳng lớn, JPEG là lựa chọn sai: cùng DCT làm nhòe các cạnh sắc với artifact ringing ("mosquito noise") và biên khối giữa các ô 8×8.

PNG (tháng 10 năm 1996 / tháng 1 năm 1997), định dạng đồ họa không mất mát

PNG (Portable Network Graphics) was developed in 1994 by an informal group outside W3C as a deliberate response to two problems with the existing options: GIF's patent encumbrance (covered below) and TIFF's complexity. The specification was approved as a W3C Recommendation on 1 October 1996, and on 15 January 1997 it was released by the IETF as RFC 2083. A second edition incorporating errata became a W3C Recommendation on 10 November 2003; a third edition adding APNG, HDR support and Exif handling was published on 24 June 2025. PNG is lossless, every encoded byte is recoverable. Internally, a PNG file is a sequence of typed chunks (IHDR header, IDAT compressed data, IEND end-of-file marker, plus optional ancillary chunks for colour profile, transparency, gamma and metadata). Pixel data is preprocessed by one of five row filters (None, Sub, Up, Average, Paeth) chosen per scanline to maximise compressibility, then run through DEFLATE, the same algorithm used in zip files and gzip. PNG supports four colour modes: greyscale, greyscale with alpha, indexed colour (palette of up to 256 entries, what people call PNG-8), and truecolor RGB (PNG-24) with optional 8-bit alpha (PNG-32). The alpha channel supports 256 levels of partial transparency per pixel, which is what makes it possible to anti-alias the edges of icons against any background without the dreaded "white halo" PNG-8 indexed transparency used to produce. PNG was designed as a web format and an archival format simultaneously, and that dual role is why it remains the default for screenshots, logos, line art, charts, and any image where pixel-perfect reproduction matters more than file size.

GIF (15 tháng 6 năm 1987), kẻ sống sót về animation và saga bằng sáng chế

Steve Wilhite, trưởng kỹ thuật tại CompuServe, giới thiệu GIF ngày 15 tháng 6 năm 1987 để giải một bài toán cụ thể: làm sao chia sẻ ảnh màu qua các modem chậm của dịch vụ online CompuServe mà tệp không ngốn hạn ngạch tháng của người dùng. Đội của ông chọn thuật toán nén Lempel-Ziv-Welch (LZW) và giới hạn bảng màu ở 256 mục. Điều CompuServe không biết năm 1987 là LZW đã được Sperry Corporation (sau là Unisys) cấp bằng sáng chế năm 1985. Vấn đề bằng sáng chế nổ ra công khai cuối 1994. Unisys công bố năm 1995 sẽ tính phí bản quyền trên phần mềm dùng thuật toán, gồm GIF, TIFF và PDF, ở mức khoảng 0,45-0,65% doanh thu. Cộng đồng web mã nguồn mở đáp lại bằng hai hành động song song: chiến dịch "Burn All GIFs" và việc thiết kế PNG, được tạo rõ ràng để là phương án thay thế GIF không bằng sáng chế. Bằng sáng chế Mỹ của Unisys hết hạn tháng 6 năm 2003; các bằng tương ứng ở khu vực khác hết hạn đến năm 2004. Năm 2004, GIF lần đầu trong lịch sử không còn vướng bằng sáng chế. GIF sống sót nhờ một tính năng PNG (ban đầu) không có: animation. Nó hỗ trợ chuỗi frame với thời gian theo từng frame và một chỉ số bảng màu trong suốt, làm nó trở thành lingua franca của ảnh phản ứng lặp và banner web. Bảng màu 256 màu là giới hạn thật cho ảnh chụp, và độ trong suốt 1-bit tạo cạnh xấu khi đặt trên nền màu, nhưng cho animation lặp ngắn nội dung kiểu hoạt hình, GIF vẫn thắng nhờ hỗ trợ phổ quát.

BMP (tháng 5 năm 1990) và TIFF (mùa thu 1986), những kẻ sống sót di sản

BMP (Bitmap, còn gọi là Windows Device Independent Bitmap) được đưa vào Windows 3.0, ra mắt ngày 22 tháng 5 năm 1990, nơi nó trở thành chuẩn cho lưu bitmap trong môi trường đồ họa Windows. Về cơ bản nó không nén, mảng pixel thô, có tùy chọn căn 4 byte mỗi dòng, với header nhỏ ở đầu. Một BMP 1920×1080 24 bit nặng khoảng 6,2 MB; cùng ảnh đó ở JPEG chất lượng 85 có thể chỉ 200 KB. Vai trò của BMP năm 2026 chủ yếu là định dạng trao đổi kế thừa và là định dạng các ảnh chụp màn hình Windows từng dùng trong lịch sử. TIFF (Tagged Image File Format) được Aldus Corporation công bố lần đầu mùa thu 1986 (Revision 3.0); Revision 6.0 tháng 6 năm 1992 thêm màu CMYK và YCbCr và JPEG-trong-TIFF. Adobe mua Aldus năm 1994 và nay giữ bản quyền. TIFF độc đáo ở chỗ là một định dạng container chứ không phải một sơ đồ mã hóa duy nhất, một tệp TIFF có thể chứa nhiều ảnh (TIFF nhiều trang, phổ biến cho fax và chương sách đã quét), dùng bất kỳ phương thức nén nào (không, LZW, ZIP, JPEG, CCITT Group 3/4 cho fax) và lưu metadata về cơ bản tùy ý qua cấu trúc trường có nhãn. Sự linh hoạt này làm TIFF trở thành mặc định cho quy trình tiền-in, quét và lưu trữ tài liệu; nó về cơ bản không bao giờ dùng cho ảnh web. Sự có mặt của nó trong danh sách đầu vào dành cho người dùng chuyển nguồn nhằm để in hoặc đã quét sang định dạng thân thiện web.

WebP (30 tháng 9 năm 2010), định dạng web hiện đại

Google công bố WebP ngày 30 tháng 9 năm 2010 như một định dạng mở mới cho đồ họa true-color nén mất mát trên web, cho ra tệp nhỏ hơn JPEG ở chất lượng tương đương. Định dạng dựa trên mã hóa keyframe của codec video VP8, mà Google đã có khi mua On2 Technologies. Ban đầu WebP chỉ có chế độ mất mát. Ngày 18 tháng 11 năm 2011, Google công bố chế độ nén không mất mát và hỗ trợ trong suốt ở cả chế độ lossless và lossy; libwebp 0.2.0 đạt triển khai lossless ổn định ngày 16 tháng 8 năm 2012. Theo tài liệu lập trình của Google: ảnh WebP không mất mát nhỏ hơn cùng ảnh ở PNG khoảng 26%, và ảnh WebP có mất mát nhỏ hơn JPEG so sánh 25-34% ở chất lượng SSIM tương đương. Những giảm này không phải phép màu, chúng đến từ thiết kế codec mới hơn về cơ bản (mã hóa intra-frame dự đoán, mã hóa entropy số học hiện đại, biến đổi màu thông minh hơn) so với nền tảng đầu thập niên 1990 mà JPEG và PNG được thiết kế đối chọi. Hỗ trợ trình duyệt xây dần: Chrome 17 tháng 2 năm 2012 (lossy), Chrome 23 tháng 11 năm 2012 (lossless). Apple cầm cự gần một thập niên và cuối cùng thêm hỗ trợ WebP trong Safari 14, ra cùng iOS 14 và macOS 11 Big Sur tháng 9 năm 2020. Ngày tháng 9 năm 2020 đó là khoảnh khắc WebP trở thành dùng được thực sự như định dạng web chính mà không cần fallback JPEG cho người dùng iPhone. Độ phủ hôm nay khoảng 97% lưu lượng toàn cầu, WebP không còn là định dạng "hiện đại" có dè dặt, đó là mặc định.

Vượt khỏi WebP: AVIF (tháng 2 năm 2019), HEIC (2017), JPEG XL (2018-)

AVIF v1.0.0 được Alliance for Open Media (AOMedia, một consortium gồm Google, Netflix, Microsoft, Mozilla, Cisco, Intel, Amazon, Apple) công bố ngày 19 tháng 2 năm 2019. Đó là profile ảnh tĩnh của codec video AV1, dựng trên container HEIF, và hiện là định dạng ảnh được triển khai rộng nhất nén tốt nhất, ở chất lượng thị giác tương đương, tệp AVIF thường nhỏ hơn JPEG 50% và nhỏ hơn WebP 20-30%. Hỗ trợ trình duyệt đến trong ba đợt: Chrome 85 (tháng 8 năm 2020), Firefox 93 (tháng 10 năm 2021), Safari với iOS 16 (tháng 9 năm 2022) và macOS Ventura (tháng 10 năm 2022). HEIC là định dạng mặc định của iPhone từ iOS 11 năm 2017, container HEIF với ảnh nén HEVC, chính thức là ISO/IEC 23008-12. Nén xuất sắc (thường nhỏ hơn JPEG 50%) nhưng HEVC bị bằng sáng chế bao quanh, đó là lý do Chrome, Firefox và Edge không-Apple từ chối giải mã HEIC nguyên gốc. JPEG XL (ISO/IEC 18181, 2022) là định dạng xuất sắc về kỹ thuật nhưng vẫn ở góc, nó có thể nén lại không mất mát các JPEG hiện hữu nhỏ hơn khoảng 20%, hỗ trợ HDR, gam màu rộng, animation và giải mã tiến dần, và không bằng sáng chế. Chrome bỏ flag thử nghiệm ngày 31 tháng 10 năm 2022 ("quyết định Halloween"); Apple ra Safari 17 tháng 9 năm 2023 với JPEG XL native trên macOS Sonoma, iOS 17 và visionOS. Định dạng được hỗ trợ native trong Safari 17+, sau flag trong Firefox và Chrome 145 (tháng 2 năm 2026), nhưng việc giao mặc định cho lưu lượng chung vẫn còn đợi. Bộ chuyển đổi này hiện không xuất AVIF, HEIC hay JPEG XL, chúng được liệt kê ở đây để bạn quyết định xử lý chúng phía thượng nguồn.

Chọn đúng định dạng đầu ra

Câu chuyện theo từng định dạng ở trên là một chuyến tham quan. Câu hỏi thực tế ngắn hơn: cho một ảnh cụ thể và một mục đích cụ thể, định dạng đầu ra nào là đúng?

Nút chất lượng thực sự làm gì

Nút chất lượng đi từ 10 đến 100 theo bước 5. Đằng sau con số đơn giản này là quan hệ phi tuyến đáng ngạc nhiên giữa chất lượng cảm nhận và kích thước tệp. Cho JPEG, đồng thuận của ngành xử lý ảnh là chất lượng 75-85 là điểm ngọt. Ở chất lượng 80, kích thước tệp giảm 70-90% so với nguồn không nén với khác biệt thị giác không cảm nhận được ở khoảng cách xem màn hình bình thường. Bước nhảy giữa chất lượng 80 và 85 dốc: một ảnh kiểm thử tiêu biểu có thể đi từ 3,7 MB ở chất lượng 80 lên 6 MB ở chất lượng 85, gần gấp đôi mà không có cải thiện thấy được trên màn hình điện thoại hay laptop. Chất lượng 75 là nơi artifact bắt đầu phát hiện được khi soi gần các chi tiết tần số cao (cạnh chữ, kết cấu mịn). Chất lượng 90 trở lên là cho JPEG lưu trữ nơi kích thước tệp không quan trọng. Mặc định 80 nằm ở đầu thấp của điểm ngọt, phù hợp cho tối ưu web theo lô, nơi mục tiêu là gửi đi ít dữ liệu nhất có thể trong khi giữ ảnh trông chấp nhận được. Cho WebP, mặc định của API canvas toBlob('image/webp') là chất lượng 0,80; WebP ở chất lượng 70 thường sạch về thị giác như JPEG ở chất lượng 80. Cho PNG, "chất lượng" là dùng từ sai, PNG luôn không mất mát trên dữ liệu pixel. Nút trên công cụ này không có tác dụng khi PNG được chọn làm định dạng đầu ra. Bài học then chốt cho xử lý theo lô: một thiết lập chất lượng duy nhất hiếm khi đúng cho mọi ảnh trong một lô hỗn hợp. Một thư mục 50 ảnh chụp bằng cùng máy ảnh trong cùng ánh sáng có thể đều lưu được ở JPEG chất lượng 80 không có vấn đề. Một thư mục trộn ảnh chụp màn hình, ảnh, line art và logo thì không thể, một cú "chuyển tất cả sang JPG-80" trong một bấm sẽ biến ảnh chụp màn hình thành mosquito noise không đọc được. Hãy chia đầu vào thành các lô riêng khi nội dung thay đổi.

Lossy và lossless, phân biệt quan trọng nhất

Bộ mã hóa lossless đảm bảo đầu ra giải mã giống hệt đầu vào đã mã hóa từng bit. PNG là lossless. WebP-lossless là lossless. TIFF (ở các chế độ lossless của nó) là lossless. Đánh đổi là kích thước tệp: bộ mã hóa lossless không thể khai thác khác biệt cảm nhận không cảm nhận được và phải giữ tất cả. Một ảnh chụp 1920×1080 ở PNG lossless có thể nặng 5 MB; cùng ảnh ở JPEG-chất-lượng-85 nặng 200 KB. PNG là chính xác từng bit; JPEG là tương đương về thị giác. Bộ mã hóa lossy bỏ thông tin mà hệ thị giác con người ít có khả năng nhận ra nhất, chi tiết tần số cao, biến đổi chroma mịn trong các màu bão hòa, chữ số có nghĩa thứ tư của mọi chuyển sắc. JPEG, WebP lossy và AVIF lossy đều làm điều đó. Hệ quả cho bộ chuyển đổi theo lô là cụ thể: lossless sang lossless (PNG sang PNG, hoặc PNG sang WebP-lossless) thực sự không mất mát qua bao nhiêu lần chuyển đổi cũng được; lossy sang lossy ở cùng chất lượng (JPEG-85 sang JPEG-85) không phải lossless, mỗi lần mã hóa lại áp dụng thêm một bước lượng tử hóa, lặp 10 lần thì kết quả suy biến thấy được; lossy sang lossless (JPEG sang PNG) đóng băng artifact hiện có nhưng không suy biến thêm; lossless sang lossy đưa vào nén mất mát tại thời điểm chuyển đổi và không có cách nào khôi phục chi tiết đã bỏ sau đó. Người dùng thường chạy lại một chuyển đổi mong đó là no-op. Ngoài trường hợp lossless-sang-lossless, không phải vậy.

EXIF, IPTC, XMP, và vì sao công cụ này gỡ chúng

Tệp JPEG và HEIC từ máy ảnh và điện thoại mang một khối EXIF, metadata Exchangeable Image File Format nhúng trong header ảnh. EXIF gồm mẫu máy ảnh, ống kính, thiết lập phơi sáng, ngày giờ, phiên bản phần mềm, và đáng kể nhất là tọa độ GPS của nơi ảnh được chụp (nếu dịch vụ vị trí được bật lúc chụp). Metadata IPTC thêm chú thích, byline, bản quyền và từ khóa. XMP, khởi nguồn từ Adobe, là siêu tập dựa trên XML bao trùm các định dạng cũ và là cái Lightroom và Photoshop dùng. Hệ quả về quyền riêng tư rất đáng kể. Một ảnh chụp trên iPhone có vị trí bật nhúng tọa độ GPS chính xác đến vài mét. Chia sẻ trên một diễn đàn, đính kèm email, hoặc qua blog cá nhân có thể tiết lộ địa chỉ nhà của nhiếp ảnh gia, trường con họ, nơi làm việc, lộ trình đi bộ. Các nền tảng xã hội lớn (Facebook, Instagram, Twitter/X) gỡ EXIF khi upload trước khi phục vụ ảnh cho người dùng khác, nhưng bản thân họ vẫn đọc và lưu metadata gốc. Diễn đàn nhỏ hơn, blog WordPress, Discord, client email và chuyển tệp trực tiếp giữ EXIF nguyên. Mã hóa lại qua API canvas (engine công cụ này dùng) bỏ tất cả metadata EXIF, IPTC và XMP theo mặc định. Đầu ra là một ảnh sạch không có nguồn gốc nhúng, một tính năng quyền riêng tư, và một hệ quả phụ của pipeline canvas (canvas chỉ lưu dữ liệu pixel; nó không có khái niệm về metadata để giữ). Người dùng muốn giữ metadata (nhiếp ảnh gia lưu trữ dữ liệu phơi sáng, quy trình nội dung nơi bản quyền phải đi cùng tệp) cần công cụ khác, thường là convert của ImageMagick hoặc thư viện chuyên có nhận thức EXIF. Bộ chuyển đổi này cắt theo hướng ngược lại: nó là gỡ-metadata theo thiết kế, đó đúng là điều người dùng quan tâm quyền riêng tư muốn khi gửi ảnh đến diễn đàn nơi họ không muốn tọa độ GPS đi theo.

Nền trong suốt, lựa chọn PNG-sang-JPEG

PNG hỗ trợ kênh alpha mỗi pixel: mỗi pixel có độ mờ từ 0 (hoàn toàn trong suốt) đến 255 (hoàn toàn đặc). JPEG không có kênh alpha. Chuyển PNG có trong suốt sang JPEG buộc một lựa chọn: pixel trong suốt phải trở thành gì? Mặc định của API canvas là composite trên nền đen trong suốt, nên JPEG kết quả phân giải pixel trong suốt thành đen đặc. Một logo trên nền trong suốt chuyển PNG-sang-JPEG ra với góc đen quanh logo, gần như không bao giờ là điều người dùng muốn. Cách giảm nhẹ là tô canvas bằng màu nền đã chọn (trắng là mặc định điển hình) trước khi vẽ ảnh lên. Người dùng cần giữ trong suốt nên chọn PNG hoặc WebP làm định dạng đầu ra. WebP hỗ trợ trong suốt ở cả chế độ lossless và lossy, làm nó là lựa chọn hiện đại khi nguồn có trong suốt và đích phải hiệu quả, một PNG nền trong suốt 50 KB có thể trở thành WebP lossy nền trong suốt 12 KB trong khi giữ kênh alpha.

Việc chuyển đổi chạy trong trình duyệt của bạn ra sao

Tuyên bố "mọi thứ chạy trong trình duyệt" dựa vào ba API của nền tảng web mà chỉ gần đây mới đủ mạnh để biến một bộ chuyển đổi ảnh theo lô thành sản phẩm phía client đáng tin cậy. FileReader API và Blob: khi bạn thả tệp vào vùng upload, mỗi File là một lớp con của Blob phơi ra hoặc readAsDataURL() (callback cũ hơn) hoặc file.arrayBuffer() (dựa trên Promise). Cho ảnh cụ thể, đường đơn giản hơn là dựng Blob URL bằng URL.createObjectURL(file) và gán cho phần tử Image mới, để bộ giải mã ảnh tích hợp của trình duyệt xử lý JPEG, PNG, GIF, WebP và BMP một cách native. Canvas API: một khi Image đã tải, việc chuyển đổi là điệu nhảy hai bước, vẽ bằng ctx.drawImage(img, 0, 0), rồi đọc canvas trở lại bằng canvas.toBlob(callback, type, quality). Tham số type là chuỗi MIME ('image/png', 'image/jpeg', 'image/webp'); tham số quality là số giữa 0 và 1 cho định dạng lossy. OffscreenCanvas và Web Workers: cho lô lớn, làm tất cả việc canvas trên thread chính sẽ chặn UI. Giải pháp hiện đại là OffscreenCanvas, phơi các thao tác canvas trong context worker và bản thân nó có thể chuyển sang Web Worker qua postMessage mà không sao chép. Worker thực thi pipeline giải mã-rasterize-mã hóa trong thread riêng, giữ trang phản hồi. Cùng nhau, các API này làm cho lô 50 tệp chạy trong vài giây mà không chặn cuộn hay bấm nút. JSZip, một thư viện thuần JavaScript giấy phép MIT, xử lý đóng gói ZIP cuối cùng hoàn toàn trong bộ nhớ trước khi hộp thoại lưu của trình duyệt xuất hiện. Không upload, không zip server, không tệp tạm trên đĩa. Một thập niên trước, một bộ chuyển đổi ảnh theo lô chạy trong trình duyệt sẽ là điều tò mò. Hiệu năng WebAssembly, song song OffscreenCanvas, và RAM điện thoại hiện đại (6-12 GB) cùng số nhân (6-8 CPU) đã đảo ngược bức tranh đó. Lập luận quyền riêng tư đóng vụ này: bộ chuyển đổi phía server đòi upload ảnh của bạn lên một máy bên thứ ba, và dù với chính sách xóa nghiêm ngặt, bản thân việc upload là sự kiện mạng có thể bị log, chặn hoặc xâm phạm. Một bộ chuyển đổi chỉ-trình-duyệt không bao giờ gửi đi một byte.

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

Định dạng hình ảnh nào được hỗ trợ?

Bộ chuyển đổi xử lý hầu hết các định dạng phổ biến (JPG, PNG, GIF, WebP, BMP, TIFF) và chuyển đổi sang PNG, JPG hoặc WebP.

Tôi có thể điều chỉnh chất lượng cho JPG và WebP không?

Có. Sử dụng thanh trượt chất lượng để điều chỉnh độ nén (0-100). Giá trị cao hơn cho chất lượng tốt hơn nhưng tệp lớn hơn.

Cách tải xuống nhiều tệp?

Chọn «Tải tất cả dưới dạng ZIP» để gói tất cả các hình ảnh đã chuyển đổi vào một kho ZIP duy nhất, tiện lợi để tải xuống và lưu trữ.

Vì sao giới hạn 50 tệp mỗi lô?

Đó là trần bộ nhớ. Mỗi ảnh phải được giải mã thành RAM dưới dạng dữ liệu pixel thô trước khi canvas có thể mã hóa lại. Một ảnh iPhone 12 megapixel giải mã thành khoảng 36 MB dữ liệu pixel (12 triệu pixel × 3 byte RGB, hoặc 4 byte RGBA). 50 cái cùng lúc là 1,8 GB bộ nhớ làm việc. Phần lớn laptop xử lý điều đó thoải mái; điện thoại cũ hơn không. Trần 50 tệp giữ trang dự đoán được qua các thiết bị. Cho lô lớn hơn, hãy chạy công cụ theo vòng, ví dụ 50 tệp, tải về, xóa, thả 50 tệp khác.

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

Không có trần cứng, giới hạn là bộ nhớ khả dụng của thiết bị bạn. Một ảnh 50 MP đơn lẻ giải mã thành khoảng 150 MB dữ liệu pixel, chạy được trên desktop nhưng sẽ vất vả trên điện thoại cũ hơn. Theo kinh nghiệm, tệp dưới 10 MB chuyển đổi mượt trên gần như mọi thiết bị; tệp trên 50 MB sẽ chậm hoặc thất bại trên di động cấp thấp. Nếu một lần chuyển đổi treo, làm mới trang và thử tệp trong lô nhỏ hơn.

Bộ chuyển đổi có gỡ metadata EXIF không?

Có, theo thiết kế. Pipeline mã hóa lại canvas chỉ lưu dữ liệu pixel, nên các khối metadata EXIF, IPTC và XMP (mẫu máy ảnh, thiết lập phơi sáng, tọa độ GPS, tag bản quyền, lịch sử chỉnh sửa) không sống sót qua vòng tròn. Đầu ra là một ảnh sạch không có nguồn gốc nhúng, đó là lợi ích quyền riêng tư khi bạn chia sẻ ảnh trên diễn đàn hoặc liên hệ email nơi bạn không muốn tọa độ GPS đi theo. Nếu bạn cần giữ metadata (nhiếp ảnh gia lưu trữ dữ liệu phơi sáng, quy trình nội dung cần tag bản quyền), đây không phải công cụ đúng, hãy dùng convert của ImageMagick hoặc thư viện chuyên có nhận thức EXIF giữ metadata một cách rõ ràng.

Điều gì xảy ra với nền trong suốt khi tôi chuyển PNG sang JPG?

JPEG không có kênh alpha, nên pixel trong suốt trong PNG nguồn phải trở thành màu đặc trong JPEG đầu ra. Hành vi mặc định của canvas là composite trên nền màu (thường là trắng). Một logo trên nền PNG trong suốt chuyển sang JPEG sẽ mất trong suốt và lấy màu nền tô. Nếu trong suốt quan trọng, hãy chọn PNG hoặc WebP làm định dạng đầu ra, cả hai đều giữ alpha. WebP-lossy giữ trong suốt ở kích thước tệp nhỏ hơn nhiều so với PNG và là lựa chọn hiện đại cho đồ họa web trong suốt.

Ảnh của tôi có bị tải lên đâu không?

Không. Mỗi bước, chọn tệp, giải mã, mã hóa lại canvas, đóng gói ZIP, tải về, chạy hoàn toàn trong trình duyệt qua JavaScript. Không có xử lý phía server. Bạn có thể kiểm chứng bằng cách mở tab Network của DevTools khi bạn chuyển đổi: không có request đi ra mang dữ liệu ảnh. Trang an toàn cho ảnh chụp màn hình nhạy cảm, scan tài liệu, ảnh cá nhân có metadata vị trí, hoặc bất cứ thứ gì bạn không muốn bị sao vào ổ cứng của người lạ.

Công cụ liên quan

PDF → HTML

Chuyển đổi PDF sang HTML ngay lập tức.

Bộ mã hóa Base64

Mã hóa hình ảnh sang Base64.

Văn bản → CSV

Chuyển đổi dữ liệu sang định dạng CSV.