Konverter Gambar Batch Gratis

Konversi beberapa gambar sekaligus antara PNG, JPG, dan WebP. Sesuaikan kualitas, bandingkan ukuran file, dan unduh semuanya seketika.

Data Anda tidak pernah meninggalkan perangkat
Jatuhkan gambar di sini atau klik untuk menelusuri (JPEG, PNG, WebP, GIF, BMP, TIFF)

Memproses…

Tentang konversi format gambar

Setiap format gambar memiliki kegunaannya. PNG tanpa kompresi, ideal untuk grafis; JPG sempurna untuk foto dan menawarkan file yang lebih kecil; dan WebP menawarkan kompresi modern dengan kualitas tinggi. Konversi batch menghemat waktu untuk memproses beberapa file.

JPEG (1992): Format Foto

Joint Photographic Experts Group dibentuk pada November 1986 di Parsippany, New Jersey, dengan anggota dari ISO TC97 SC2/WG8 dan grup CCITT SGVIII. Enam tahun pekerjaan komite kemudian, teks CCITT Recommendation T.81 disetujui pada 18 September 1992, dengan teks identik diterbitkan sebagai ISO/IEC International Standard 10918-1 pada 1994. Publikasi dua-dokumen itu adalah momen JPEG menjadi format foto dunia. Inti matematisnya adalah transformasi kosinus diskrit yang diterapkan pada blok pixel 8×8: setiap blok diuraikan menjadi jumlah gelombang kosinus, komponen frekuensi-tinggi yang penglihatan manusia paling tidak sensitif terhadapnya dikuantisasi lebih agresif daripada yang frekuensi-rendah yang mata perhatikan terlebih dahulu. Slider "kualitas" yang menghadap pengguna persis ini: pengali pada tabel kuantisasi. Kualitas lebih tinggi berarti pembagi yang lebih kecil, lebih banyak presisi, file yang lebih besar. Kualitas lebih rendah berarti lebih banyak nol setelah kuantisasi, pengkodean entropi yang lebih baik, dan file yang lebih kecil dengan biaya artefak blocking dan ringing yang terlihat. JPEG bersifat lossy berdasarkan desain: tidak ada pengaturan kualitas di mana round-trip JPEG identik secara matematis dengan inputnya. Untuk foto-foto adegan alami: wajah, lanskap, makanan, apa pun dengan gradien halus dan tone kontinu: ini tidak relevan; kerugian hidup di bawah ambang sensitivitas penglihatan manusia dan file adalah sebagian kecil dari ukuran yang akan dihasilkan format lossless. Untuk grafik dengan tepi keras, teks, line art, atau area warna datar besar, JPEG adalah pilihan yang salah: DCT yang sama mengoles tepi tajam dengan artefak ringing ("mosquito noise") dan batas blok antara sel 8×8.

PNG (Oktober 1996 / Januari 1997): Format Grafis Lossless

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 Juni 1987): Yang Bertahan untuk Animasi dan Saga Paten

Steve Wilhite, lead engineering di CompuServe, memperkenalkan GIF pada 15 Juni 1987 untuk memecahkan masalah spesifik: cara berbagi gambar warna di seluruh modem lambat layanan online CompuServe tanpa file menelan kuota bulanan pengguna. Timnya memilih algoritma kompresi Lempel-Ziv-Welch (LZW) dan membatasi palet warna pada 256 entri. Apa yang tidak diketahui CompuServe pada 1987 adalah bahwa LZW telah dipatenkan oleh Sperry Corporation (kemudian Unisys) pada 1985. Masalah paten meledak ke pandangan publik pada akhir 1994. Unisys mengumumkan pada 1995 akan mengenakan royalti pada perangkat lunak yang menggunakan algoritma: termasuk GIF, TIFF, dan PDF: pada tarif sekitar 0,45% hingga 0,65% dari pendapatan. Komunitas open-source web merespons dengan dua tindakan paralel: kampanye "Burn All GIFs" dan desain PNG, secara eksplisit untuk menjadi pengganti GIF bebas-paten. Paten Unisys AS berakhir pada Juni 2003; paten yang sesuai di yurisdiksi lain berakhir hingga 2004. Pada 2004, GIF adalah bebas-paten untuk pertama kalinya dalam sejarahnya. GIF bertahan karena satu fitur yang tidak dimiliki PNG (awalnya): animasi. Itu mendukung urutan frame dengan timing penundaan per-frame dan indeks palet transparan, menjadikannya lingua franca dari gambar reaksi looping dan banner web. Palet 256-warna adalah keterbatasan nyata untuk foto, dan transparansi 1-bit menghasilkan tepi jelek saat overlay pada latar belakang berwarna, tetapi untuk animasi looping pendek konten gaya-kartun, GIF masih menang dalam dukungan universal.

BMP (Mei 1990) dan TIFF (musim gugur 1986): Yang Bertahan Legacy

BMP (Bitmap, juga disebut Windows Device Independent Bitmap) dimasukkan ke dalam Windows 3.0, dirilis pada 22 Mei 1990, di mana itu menjadi standar untuk penyimpanan bitmap di lingkungan grafis Windows. Itu pada dasarnya tidak dikompresi: array pixel mentah, opsional diselaraskan-baris ke batas 4-byte, dengan header kecil di depan. BMP 24-bit 1920×1080 sekitar 6,2 MB; gambar yang sama sebagai JPEG kualitas-85 mungkin 200 KB. Peran BMP pada 2026 pada dasarnya sebagai format pertukaran legacy dan format yang secara historis digunakan screenshot Windows. TIFF (Tagged Image File Format) pertama kali diterbitkan oleh Aldus Corporation pada musim gugur 1986 (Revisi 3.0); Revisi 6.0 pada Juni 1992 menambahkan warna CMYK dan YCbCr serta JPEG-in-TIFF. Adobe mengakuisisi Aldus pada 1994 dan sekarang memegang hak ciptanya. TIFF unik dalam menjadi format kontainer daripada skema pengkodean tunggal: satu file TIFF dapat menampung beberapa gambar (TIFF multi-halaman, umum untuk fax dan bab buku yang dipindai), menggunakan salah satu dari beberapa metode kompresi (tidak ada, LZW, ZIP, JPEG, CCITT Group 3/4 untuk fax) dan menyimpan metadata yang pada dasarnya sembarang melalui struktur field-tagged-nya. Fleksibilitas ini menjadikan TIFF default untuk alur kerja prepress, pemindaian, dan arsip dokumen; itu pada dasarnya tidak pernah digunakan untuk gambar web. Kehadirannya dalam daftar input adalah untuk pengguna yang mengonversi sumber yang terikat-cetak atau dipindai ke format ramah-web.

WebP (30 September 2010): Format Web Modern

Google mengumumkan WebP pada 30 September 2010 sebagai format terbuka baru untuk grafik warna-sejati yang dikompresi lossy di web, menghasilkan file yang lebih kecil dari JPEG pada kualitas yang sebanding. Format ini didasarkan pada pengkodean keyframe dari codec video VP8, yang Google peroleh dengan pembelian On2 Technologies. Awalnya WebP hanya lossy. Pada 18 November 2011, Google mengumumkan mode kompresi lossless dan dukungan transparansi baik dalam mode lossless maupun lossy; libwebp 0.2.0 mencapai implementasi lossless yang stabil pada 16 Agustus 2012. Per dokumentasi pengembang Google: gambar WebP lossless sekitar 26% lebih kecil dari gambar yang sama dalam PNG, dan gambar WebP lossy 25-34% lebih kecil dari JPEG yang sebanding pada kualitas SSIM yang setara. Pengurangan ini bukan sihir: mereka berasal dari desain codec yang fundamental lebih baru (pengkodean intra-frame prediktif, pengkodean entropi aritmetika modern, transformasi warna yang lebih cerdas) daripada baseline awal-1990-an yang JPEG dan PNG dirancang. Dukungan browser adalah pembangunan lambat: Chrome 17 pada Februari 2012 (lossy), Chrome 23 pada November 2012 (lossless). Apple bertahan untuk sebagian besar dekade dan akhirnya menambahkan dukungan WebP di Safari 14, yang dirilis dengan iOS 14 dan macOS 11 Big Sur pada September 2020. Tanggal September 2020 itu adalah momen WebP menjadi praktis dapat digunakan sebagai format web utama tanpa fallback JPEG untuk pengguna iPhone. Cakupan hari ini sekitar 97% dari lalu lintas global: WebP bukan lagi format "modern" dengan peringatan, itu adalah default.

Di Luar WebP: AVIF (Feb 2019), HEIC (2017), JPEG XL (2018-)

AVIF v1.0.0 dirilis pada 19 Februari 2019 oleh Alliance for Open Media (AOMedia, konsorsium Google, Netflix, Microsoft, Mozilla, Cisco, Intel, Amazon, Apple). Itu adalah profil gambar-diam dari codec video AV1, dibangun di atas kontainer HEIF, dan saat ini adalah format gambar yang paling mengompresi dan banyak digunakan: pada kualitas visual yang setara, file AVIF biasanya 50% lebih kecil dari JPEG dan 20-30% lebih kecil dari WebP. Dukungan browser tiba dalam tiga gelombang: Chrome 85 (Agustus 2020), Firefox 93 (Oktober 2021), Safari dengan iOS 16 (September 2022) dan macOS Ventura (Oktober 2022). HEIC adalah format default iPhone sejak iOS 11 pada 2017: kontainer HEIF dengan gambar yang dikompresi HEVC, secara formal ISO/IEC 23008-12. Kompresinya sangat baik (biasanya 50% lebih kecil dari JPEG) tetapi HEVC dibebani paten, itulah mengapa Chrome, Firefox, dan Edge non-Apple menolak untuk men-decode HEIC secara native. JPEG XL (ISO/IEC 18181, 2022) adalah format niche yang sangat baik secara teknis: dapat melakukan rekompresi lossless JPEG yang ada menjadi ~20% lebih kecil, mendukung HDR, gamma luas, animasi, dan decoding progresif, dan bebas-paten. Chrome menjatuhkan flag eksperimentalnya pada 31 Oktober 2022 ("keputusan Halloween"); Apple mengirim Safari 17 pada September 2023 dengan JPEG XL native di seluruh macOS Sonoma, iOS 17, dan visionOS. Format ini didukung secara native di Safari 17+, di balik flag di Firefox dan Chrome 145 (Februari 2026), tetapi pengiriman default untuk lalu lintas umum tetap tertunda. Konverter ini saat ini tidak memancarkan AVIF, HEIC, atau JPEG XL: mereka tercantum di sini sehingga Anda dapat memutuskan apakah akan menanganinya di hulu.

Memilih Format Output yang Tepat

Sejarah format-demi-format di atas adalah tur. Pertanyaan praktisnya lebih singkat: diberi gambar tertentu dan penggunaan tertentu, format output mana yang benar?

Apa yang Sebenarnya Dilakukan Slider Kualitas

Slider kualitas berjalan dari 10 hingga 100 dalam langkah 5. Di balik angka tunggal itu adalah hubungan yang sangat tidak linear antara kualitas yang dirasakan dan ukuran file. Untuk JPEG, konsensus di seluruh teknik pemrosesan gambar adalah bahwa kualitas 75-85 adalah sweet spot. Pada kualitas 80, ukuran file turun 70-90% dari sumber yang tidak dikompresi dengan perbedaan visual yang tidak dapat dirasakan pada jarak pandang layar normal. Penurunan antara kualitas 80 dan 85 curam: gambar uji representatif mungkin berpindah dari 3,7 MB pada kualitas 80 menjadi 6 MB pada kualitas 85, hampir penggandaan tanpa peningkatan yang terlihat pada layar telepon atau laptop. Kualitas 75 adalah di mana artefak mulai dapat dideteksi pada inspeksi dekat detail frekuensi-tinggi (tepi teks, tekstur halus). Kualitas 90 dan di atasnya adalah untuk JPEG arsip di mana ukuran file tidak relevan. Default 80 berada di ujung bawah sweet spot: cocok untuk optimasi web batch, di mana tujuannya adalah mengirim sesedikit mungkin data sambil menjaga gambar yang terlihat dapat diterima. Untuk WebP, default API canvas toBlob('image/webp') adalah kualitas 0,80; WebP pada kualitas 70 umumnya secara visual sebersih JPEG pada kualitas 80. Untuk PNG, "kualitas" adalah keliru: PNG selalu lossless pada data pixel. Slider di alat ini tidak berpengaruh ketika PNG dipilih sebagai format output. Pelajaran penting untuk pemrosesan batch: pengaturan kualitas tunggal jarang benar untuk setiap gambar dalam batch campuran. Folder 50 foto yang diambil pada kamera yang sama dalam pencahayaan yang sama mungkin semua dapat disimpan pada kualitas JPEG 80 tanpa kerugian. Folder yang mencampur screenshot, foto, line art, dan logo tidak bisa: "konversi semua ke JPG-80" sekali tombol akan mengubah screenshot menjadi mosquito-noise yang tidak terbaca. Bagi input ke dalam batch terpisah saat konten bervariasi.

Lossy vs Lossless: Perbedaan Paling Penting

Encoder lossless menjamin output yang di-decode identik bit dengan input yang dikodekan. PNG adalah lossless. WebP-lossless adalah lossless. TIFF (dalam mode lossless-nya) adalah lossless. Trade-off-nya adalah ukuran file: encoder lossless tidak dapat memanfaatkan perbedaan perseptual yang tidak dapat dirasakan dan harus mempertahankan semuanya. Foto 1920×1080 sebagai PNG lossless mungkin 5 MB; foto yang sama sebagai JPEG-kualitas-85 adalah 200 KB. PNG sempurna-bit; JPEG secara visual setara. Encoder lossy membuang informasi yang sistem visual manusia paling tidak mungkin perhatikan: detail frekuensi-tinggi, variasi kroma halus dalam warna jenuh, angka signifikan keempat dari setiap gradien. JPEG, WebP lossy, dan AVIF lossy semua melakukan ini. Implikasinya untuk konverter batch konkret: lossless ke lossless (PNG ke PNG, atau PNG ke WebP-lossless) benar-benar lossless di sejumlah konversi; lossy ke lossy pada kualitas yang sama (JPEG-85 ke JPEG-85) tidak lossless: setiap re-encode menerapkan langkah kuantisasi lain, ulangi 10 kali dan hasilnya secara visual terdegradasi; lossy ke lossless (JPEG ke PNG) membekukan artefak yang ada di tempat tetapi tidak mendegradasi ulang mereka; lossless ke lossy memperkenalkan kompresi lossy pada saat konversi dan tidak ada cara untuk memulihkan detail yang dibuang nanti. Pengguna sering menjalankan ulang konversi mengharapkannya menjadi no-op. Di luar kasus lossless-ke-lossless, itu tidak.

EXIF, IPTC, XMP: dan Mengapa Alat Ini Menghapusnya

File JPEG dan HEIC dari kamera dan telepon membawa blok EXIF: metadata Exchangeable Image File Format yang disematkan di header gambar. EXIF mencakup model kamera, lensa, pengaturan eksposur, tanggal dan waktu, versi perangkat lunak, dan yang paling konsekuensial koordinat GPS dari mana foto diambil (jika layanan lokasi aktif pada waktu pengambilan). Metadata IPTC menambahkan caption, byline, hak cipta, dan kata kunci. XMP, awalnya dari Adobe, adalah superset berbasis-XML yang mencakup format yang lebih lama dan itulah yang digunakan Lightroom dan Photoshop. Implikasi privasinya signifikan. Foto yang diambil di iPhone dengan lokasi aktif menyematkan koordinat GPS yang akurat dalam beberapa meter. Membagikannya di forum, dalam lampiran email, atau melalui blog pribadi dapat mengungkapkan alamat rumah fotografer, sekolah anak mereka, tempat kerja mereka, rute pendakian mereka. Platform sosial utama (Facebook, Instagram, Twitter/X) menghapus EXIF saat upload sebelum menyajikan gambar ke pengguna lain: tetapi mereka membaca dan menyimpan metadata asli sendiri. Forum yang lebih kecil, blog WordPress, Discord, klien email, dan transfer file langsung membiarkan EXIF utuh. Pengkodean ulang melalui API canvas (mesin yang digunakan alat ini) membuang semua metadata EXIF, IPTC, dan XMP secara default. Output adalah gambar bersih tanpa provenans yang disematkan: fitur privasi, dan efek samping dari pipeline canvas (canvas hanya menyimpan data pixel; tidak memiliki gagasan tentang metadata yang harus dipertahankan). Pengguna yang ingin mempertahankan metadata (fotografer yang mengarsipkan data eksposur, alur kerja konten di mana hak cipta harus berjalan dengan file) memerlukan alat yang berbeda: biasanya convert ImageMagick atau pustaka khusus EXIF-aware. Konverter ini memotong cara lain: itu menghapus metadata berdasarkan desain, yang persis apa yang diinginkan pengguna yang sadar privasi saat mengirim gambar ke forum di mana mereka tidak ingin koordinat GPS mereka ikuti.

Latar Belakang Transparan: Pilihan PNG-ke-JPEG

PNG mendukung saluran alpha per-pixel: setiap pixel memiliki opasitas dari 0 (sepenuhnya transparan) hingga 255 (sepenuhnya opak). JPEG tidak memiliki saluran alpha. Mengonversi PNG dengan transparansi ke JPEG memaksa pilihan: apa yang harus dijadikan pixel transparan? Default API canvas adalah membuat composite terhadap hitam transparan, sehingga JPEG yang dihasilkan menyelesaikan pixel transparan menjadi hitam opak. Logo pada latar belakang transparan yang dikonversi PNG-ke-JPEG keluar dengan sudut hitam di sekitar logo: hampir tidak pernah apa yang diinginkan pengguna. Mitigasinya adalah mengisi canvas dengan warna latar belakang yang dipilih (putih adalah default tipikal) sebelum menggambar gambar di atas. Pengguna yang perlu mempertahankan transparansi harus memilih PNG atau WebP sebagai format output. WebP mendukung transparansi baik dalam mode lossless maupun lossy, yang menjadikannya pilihan modern saat sumber memiliki transparansi dan tujuan harus efisien: PNG latar-belakang-transparan 50 KB mungkin menjadi WebP lossy latar-belakang-transparan 12 KB sambil mempertahankan saluran alpha.

Bagaimana Konversi Berjalan di Browser Anda

Klaim "semuanya berjalan di browser Anda" bertumpu pada tiga API Web Platform yang baru-baru ini menjadi cukup kuat untuk menjadikan konverter gambar batch produk sisi-klien yang kredibel. API FileReader dan Blob: ketika Anda menjatuhkan file ke zona upload, setiap File adalah subkelas Blob yang mengekspos baik readAsDataURL() (callback lebih lama) atau file.arrayBuffer() (berbasis Promise). Untuk gambar khususnya, jalur yang lebih sederhana adalah membangun Blob URL dengan URL.createObjectURL(file) dan menetapkannya ke elemen Image baru, membiarkan decoder gambar built-in browser menangani JPEG, PNG, GIF, WebP, dan BMP secara native. API Canvas: setelah Image dimuat, konversi adalah tarian dua langkah: gambar dengan ctx.drawImage(img, 0, 0), lalu baca canvas kembali dengan canvas.toBlob(callback, type, quality). Parameter type adalah string MIME ('image/png', 'image/jpeg', 'image/webp'); parameter quality adalah angka antara 0 dan 1 untuk format lossy. OffscreenCanvas dan Web Workers: untuk batch besar, melakukan semua pekerjaan canvas di thread utama memblokir UI. Solusi modernnya adalah OffscreenCanvas, yang mengekspos operasi canvas dalam konteks worker dan itu sendiri dapat dipindahkan ke Web Worker melalui postMessage tanpa menyalin. Worker menjalankan pipeline decode-rasterisasi-encode di thread terpisah, menjaga halaman responsif. Bersama-sama API ini membuat batch 50-file berjalan dalam hitungan detik tanpa memblokir scrolling atau klik tombol. JSZip: pustaka pure-JavaScript berlisensi MIT: menangani pengemasan ZIP akhir sepenuhnya di memori sebelum dialog penyimpanan browser dipicu. Tidak ada upload, tidak ada zip server, tidak ada file sementara di disk. Satu dekade lalu konverter gambar batch yang berjalan di browser akan menjadi keingintahuan. Kinerja WebAssembly, paralelisme OffscreenCanvas, dan RAM telepon modern (6-12 GB) dan jumlah core (6-8 CPU) telah membalik gambar itu. Argumen privasi menutup kasus: konverter sisi-server memerlukan upload gambar Anda ke mesin pihak ketiga, dan bahkan dengan kebijakan penghapusan yang teliti, upload itu sendiri adalah peristiwa jaringan yang dapat dicatat, dicegat, atau dilanggar. Konverter browser-only tidak pernah mengirim byte.

Pertanyaan umum

Format gambar apa saja yang didukung?

Konverter memproses sebagian besar format umum (JPG, PNG, GIF, WebP, BMP, TIFF) dan mengonversi ke PNG, JPG, atau WebP.

Bisakah saya menyesuaikan kualitas untuk JPG dan WebP?

Ya. Gunakan slider kualitas untuk menyesuaikan kompresi (0-100). Nilai yang lebih tinggi memberikan kualitas yang lebih baik tetapi file yang lebih besar.

Bagaimana saya mengunduh beberapa file?

Pilih "Unduh semua sebagai ZIP" untuk mengelompokkan semua gambar yang dikonversi dalam satu arsip ZIP, mudah untuk diunduh dan disimpan.

Mengapa batas adalah 50 file per batch?

Itu adalah plafon memori. Setiap gambar harus didekode ke RAM sebagai data pixel mentah sebelum canvas dapat mengkode ulangnya. Foto iPhone 12-megapixel mendekode ke sekitar 36 MB data pixel (12 juta pixel × 3 byte RGB, atau 4 byte RGBA). 50 dari itu sekaligus adalah 1,8 GB memori kerja. Sebagian besar laptop menanganinya dengan nyaman; telepon yang lebih lama tidak. Tutup 50-file menjaga halaman dapat diprediksi di seluruh perangkat. Untuk batch yang lebih besar, jalankan alat dalam putaran: katakan, 50 file, unduh, hapus, jatuhkan 50 lagi.

Apakah ada batas ukuran per-file?

Tidak ada cap keras: batasnya adalah memori yang tersedia perangkat Anda. Gambar 50 MP tunggal mendekode ke sekitar 150 MB data pixel, yang berfungsi di desktop tetapi akan kesulitan di telepon yang lebih lama. Sebagai aturan umum, file di bawah 10 MB dikonversi dengan mulus pada dasarnya pada perangkat apa pun; file di atas 50 MB akan melambat atau gagal pada mobile kelas bawah. Jika konversi membeku, segarkan halaman dan coba file dalam batch yang lebih kecil.

Apakah konverter menghapus metadata EXIF?

Ya: berdasarkan desain. Pipeline pengkodean ulang canvas hanya menyimpan data pixel, sehingga blok metadata EXIF, IPTC, dan XMP (model kamera, pengaturan eksposur, koordinat GPS, tag hak cipta, riwayat pengeditan) tidak bertahan dari round-trip. Output adalah gambar bersih tanpa provenans yang disematkan, yang merupakan kemenangan privasi saat Anda berbagi foto ke forum atau kontak email di mana Anda tidak ingin koordinat GPS ikuti. Jika Anda memerlukan metadata dipertahankan (fotografer mengarsipkan data eksposur, alur kerja konten yang memerlukan tag hak cipta), ini adalah alat yang salah: gunakan convert ImageMagick atau pustaka khusus EXIF-aware yang secara eksplisit mempertahankan metadata.

Apa yang terjadi pada latar belakang transparan ketika saya mengonversi PNG ke JPG?

JPEG tidak memiliki saluran alpha, sehingga pixel transparan dalam PNG sumber harus menjadi beberapa warna opak dalam output JPEG. Perilaku default canvas adalah membuat composite terhadap latar belakang berwarna (biasanya putih). Logo pada latar belakang PNG transparan yang dikonversi ke JPEG akan kehilangan transparansi dan mengambil pengisian latar belakang. Jika transparansi penting, pilih PNG atau WebP sebagai format output: keduanya mempertahankan alpha. WebP-lossy mempertahankan transparansi pada ukuran file yang dramatis lebih kecil dari PNG dan merupakan pilihan modern untuk grafik web transparan.

Apakah gambar saya diunggah ke mana pun?

Tidak. Setiap langkah: pemilihan file, decode, pengkodean ulang canvas, pengemasan ZIP, unduh: berjalan sepenuhnya di browser Anda melalui JavaScript. Tidak ada pemrosesan sisi-server. Anda dapat memverifikasi dengan membuka tab Network DevTools browser Anda saat Anda mengonversi: tidak ada permintaan keluar yang membawa data gambar. Halaman aman untuk screenshot sensitif, pemindaian dokumen, foto pribadi dengan metadata lokasi, atau apa pun yang tidak ingin Anda salin ke hard drive orang asing.

Alat terkait

PDF → HTML

Konversi PDF ke HTML seketika.

Encoder Base64

Enkode gambar ke Base64.

Teks → CSV

Konversi data ke format CSV.