Kompresor Gambar Gratis Online

Cara Kerjanya

1. Pilih atau letakkan satu atau beberapa gambar di atas.
2. Sesuaikan slider kualitas (lebih rendah = file lebih kecil, kompresi lebih tinggi).
3. Gambar dikompres di browser Anda · tidak ada yang diunggah.
4. Unduh gambar terkompresi satu per satu atau semuanya sekaligus.

Mengapa Mengompres Gambar?

Gambar besar memperlambat situs web, meningkatkan bounce rate, dan merusak peringkat Google Anda. Mengompres gambar mengurangi ukuran file sebesar 50-80% dengan kehilangan kualitas visual yang minimal. Ini penting bagi pengembang web, blogger, toko e-commerce, dan siapa pun yang menerbitkan konten secara online. Gambar yang lebih kecil juga menghemat bandwidth pada perangkat seluler dan meningkatkan skor Core Web Vitals.

Apa arti sebenarnya dari kompresi gambar

Kompresi gambar mencakup dua operasi yang fundamentalnya berbeda yang berbagi nama. Kompresi lossy, digunakan oleh JPEG dan WebP lossy, membuang data gambar yang tidak mungkin diperhatikan mata manusia (gradasi halus dalam detail bayangan, kebisingan frekuensi tinggi, chroma subsampling untuk rasio warna-vs-kecerahan yang disesuaikan dengan penglihatan manusia). Outputnya lebih kecil dari input tetapi tidak dapat direkonstruksi bit demi bit. Kompresi lossless, digunakan oleh PNG, GIF, TIFF-LZW, dan WebP lossless, mengkodekan data piksel yang tepat lebih kompak menggunakan algoritma seperti DEFLATE (LZ77 + Huffman). Outputnya lebih kecil, dan dekompresi mereproduksi byte asli demi byte. Mana yang benar tergantung pada gambar: fotografi mentolerir lossy dengan indah karena kontennya penuh dengan tekstur yang tidak dapat dilacak mata pada tingkat piksel; logo, screenshot, dan grafik dengan transisi warna tajam menuntut lossless karena setiap piksel disengaja.

Pengaturan kualitas di kompresor JPEG (slider pada alat ini, 10-100%) mengontrol tabel kuantisasi yang diterapkan setelah langkah DCT. Pada kualitas 100, tabel-tabel hampir tidak membulatkan koefisien frekuensi; pada kualitas 50, mereka membulatkan dengan agresif. Kualitas yang lebih tinggi berarti file yang lebih besar dengan detail yang lebih halus; kualitas yang lebih rendah berarti file yang lebih kecil dengan artefak berblok yang terlihat di area datar. Default 60% berada di sweet spot untuk penggunaan web: biasanya pengurangan ukuran file 50-80% tanpa perubahan yang terlihat di layar tipikal. Untuk cetak atau pekerjaan tampilan besar, dorong ke 80-90%. Untuk thumbnail atau versi ramah email, 30-50% baik-baik saja.

Untuk PNG, slider kualitas tidak berlaku dalam arti biasa karena PNG selalu lossless. Apa yang sebenarnya alat ini lakukan untuk input PNG adalah menjalankan pass DEFLATE yang lebih kuat daripada yang dilakukan sebagian besar perangkat lunak authoring (Photoshop, Affinity, Sketch) secara default; itu biasanya menekan 5-25% dari ukuran file tanpa perubahan piksel. Dropdown Format juga memungkinkan Anda mengubah PNG menjadi JPEG atau WebP, yang menukar lossless untuk file yang jauh lebih kecil tetapi kehilangan transparansi untuk output JPEG dan (untuk konten fotografi) jaminan lossless untuk WebP. Opsi Lebar Maksimum mengubah ukuran gambar selama kompresi: foto lebar 4000 piksel diperkecil menjadi 1920 piksel menghemat 75% pada jumlah piksel mentah sebelum kompresi apa pun bahkan berjalan, jadi itu menumpuk dengan pengurangan kualitas.

Bagaimana alat ini bekerja di balik layar

Mesin kompresi adalah browser-image-compression oleh Donald Wong (GitHub: Donaldcwl/browser-image-compression, lisensi MIT). Ini adalah library JavaScript murni, sekitar 95 KB minified, yang membungkus tiga primitive browser: File API untuk membaca byte, Canvas API (atau OffscreenCanvas saat tersedia) untuk mendekode, mengubah ukuran, dan re-encode gambar JPEG/WebP, dan UZIP (library DEFLATE kecil) untuk menangani PNG tanpa melalui Canvas. Saat Anda menjatuhkan gambar, browser menyerahkan byte ke library; library memilih jalur berdasarkan format input dan output yang diminta.

Untuk input JPEG dan WebP, jalurnya adalah dekode-ke-canvas, opsional mengubah ukuran ke Lebar Maksimum yang dikonfigurasi, lalu memanggil canvas.toBlob(mimeType, quality/100). Encoder JPEG atau WebP bawaan browser melakukan kuantisasi dan pengkodean Huffman yang sebenarnya. Kualitas adalah nilai slider Anda dibagi 100, diteruskan sebagai argumen kedua. Untuk input PNG yang dipertahankan sebagai PNG, library melewati Canvas sepenuhnya (round-trip Canvas akan re-rasterize data lossless yang tidak perlu) dan sebagai gantinya menjalankan UZIP atas potongan IDAT dari file PNG secara langsung, dengan upaya kompresi maksimum. Inilah sebabnya mengapa kompresi PNG-ke-PNG di sini benar-benar lossless: data piksel tidak pernah didekode dan re-encode, hanya pembungkus DEFLATE yang diperketat.

Saat OffscreenCanvas didukung (Chrome modern, Edge, Safari, Firefox), pekerjaan berat decode-resize-encode berjalan di dalam Web Worker, menjaga thread UI utama tetap responsif. Anda dapat menjatuhkan batch 20 foto dan terus menggulir halaman saat masing-masing diproses. Pada browser yang lebih lama, library jatuh kembali ke thread utama, yang masih berfungsi tetapi memblokir halaman selama pekerjaan besar. Seluruh pipeline berjalan di dalam tab Anda. Library dimuat sekali dari CDN (sekitar 95 KB minified) pada kunjungan pertama, di-cache setelahnya. Tidak ada konten file yang pernah meninggalkan browser. Buka tab Network di DevTools saat Anda mengompres batch dan Anda akan melihat fetch library satu kali tetapi tidak ada yang lain.

Sejarah singkat format kompresi gambar

• DCT, 1972-1974. Nasir Ahmed mengusulkan discrete cosine transform sebagai metode untuk kompresi gambar pada tahun 1972; algoritma formal diterbitkan dengan T. Natarajan dan K. R. Rao pada tahun 1974. Transformasi matematika tunggal ini berada di bawah setiap file JPEG, MPEG, dan video H.26x di dunia hari ini.
• JPEG, 1992. Joint Photographic Experts Group (dibentuk 1986) menstandarisasi JPEG sebagai ITU-T T.81 / ISO/IEC 10918-1 pada tahun 1992. Blok DCT 8x8, warna YCbCr dengan chroma subsampling opsional, tabel kuantisasi yang disesuaikan untuk penglihatan manusia. Format yang memungkinkan web kaya foto.
• PNG, 1996. Dibuat di IETF sebagai RFC 2083 untuk menggantikan GIF setelah klaim paten LZW Unisys mengancam web terbuka. Kompresi DEFLATE (LZ77 + Huffman), selalu lossless, transparansi alfa penuh, tanpa beban paten. Spesifikasi 3rd Edition (W3C, 2023) menambahkan HDR, animasi APNG, dan metadata EXIF secara resmi.
• WebP, 2010. Google merilis WebP sebagai format gambar still berdasarkan pengkodean intra-frame codec video VP8. WebP lossy berjalan 25-34% lebih kecil daripada JPEG pada kualitas visual yang sebanding; WebP lossless berjalan sekitar 26% lebih kecil daripada PNG. Adopsi memakan waktu satu dekade; pada tahun 2026, lebih dari 96% browser di seluruh dunia mendukungnya.
• AVIF, 2019. Alliance for Open Media merilis AVIF sebagai varian gambar still dari codec video AV1. Kira-kira 50% lebih kecil dari JPEG pada kualitas yang sebanding. Dukungan browser sekarang 95%+ tetapi dukungan encoder dalam alat authoring sehari-hari (Photoshop, Word, Slack) tertinggal. Squoosh dan ImageMagick dapat memproduksi AVIF hari ini; sebagian besar kamera dan ponsel tidak bisa.
• HEIC, 2017. Apple mengadopsi HEIF/HEIC berbasis H.265 sebagai format foto default iPhone. Sekitar setengah ukuran JPEG yang setara. Terbebani royalti, sehingga jarang disajikan di web terbuka. Sebagian besar uploader online (termasuk alat ini) menerima HEIC hanya setelah konversi desktop ke JPEG; konversi itu adalah alur kerja sehari-hari untuk mengirim foto ponsel ke penerima non-Apple.

Format yang Didukung

• JPEG · Terbaik untuk foto dan gambar kompleks. Kompresi lossy dengan kualitas yang dapat disesuaikan.
• PNG · Terbaik untuk grafik, logo, dan gambar dengan transparansi.
• WebP · Format modern dari Google yang menawarkan file lebih kecil daripada JPEG/PNG dengan kualitas sebanding.

Alur kerja kompresi dunia nyata

• Gambar blog dan situs web. JPEG 2 MB langsung dari kamera ponsel vs JPEG terkompresi 250 KB: identik di mata manusia pada layar tipikal, tetapi file yang lebih kecil dimuat sekitar 8x lebih cepat. Skor Core Web Vitals (LCP) meningkat secara langsung. Sebagian besar halaman dengan beberapa foto melihat peningkatan kinerja Lighthouse terbesar dari kompresi gambar, bukan dari optimasi JavaScript atau CSS.
• Unggahan media sosial. Instagram, Twitter, Facebook, LinkedIn semuanya mengompres ulang gambar saat diunggah menggunakan algoritma mereka sendiri. Mengompres terlebih dahulu memberi Anda kontrol atas apa yang dikorbankan; mengunggah foto mentah berarti platform membuat pilihan-pilihan itu untuk Anda, sering dengan degradasi yang terlihat.
• Lampiran email. Sebagian besar penyedia membatasi lampiran pada 25 MB per pesan (Gmail, Outlook, Apple Mail). Mengompres folder foto dari ~50 MB ke ~10 MB memungkinkan Anda mengirim semuanya dalam satu email alih-alih membagi ke beberapa pengiriman atau pindah ke tautan berbagi cloud.
• Foto produk e-commerce. Katalog produk dengan ratusan atau ribuan foto melihat tagihan bandwidth CDN besar dan pemuatan halaman lambat. Mengompres seluruh library memotong keduanya. Penjual Shopify, Etsy, dan Amazon umumnya mengompres sebelum mengunggah untuk menurunkan biaya hosting dan meningkatkan peringkat pencarian.
• Portofolio yang banyak screenshot. Portofolio desain UI berat PNG karena screenshot memiliki transisi warna tajam di mana artefak JPEG akan terlihat. PNG-ke-PNG melalui DEFLATE yang lebih ketat biasanya menghemat 10-20% tanpa perubahan piksel, berguna untuk situs portofolio desainer yang perlu tetap cepat tanpa mengorbankan kualitas rendering.
• Pengecilan arsip. Foto 12 megapiksel dari ponsel berlebihan untuk album berbagi keluarga yang hanya akan dilihat di layar. Ubah ukuran menjadi 4 megapiksel dengan kualitas 80%: hasilnya terlihat identik di setiap perangkat yang akan pernah melihatnya, dan arsip menyusut menjadi seperlima dari ukuran aslinya. Aslinya tetap aman di disk sumber; versi terkompresi pergi ke share atau backup.

Jebakan umum dan artinya

• Mengompres ulang JPEG beberapa kali mendegradasinya. Setiap penyimpanan JPEG menjalankan ulang langkah kuantisasi DCT, kehilangan detail yang tidak pernah dapat Anda pulihkan. Kerugian halus pada pass pertama dan jelas pada pass ketiga atau keempat. Selalu kompres dari sumber kualitas tertinggi yang Anda miliki (file kamera asli, ekspor dari alat desain Anda), bukan dari JPEG yang sebelumnya dikompres yang Anda simpan minggu lalu. Jika Anda perlu melakukan penyesuaian, simpan salinan master dalam PNG atau TIFF.
• PNG-ke-JPEG menjatuhkan transparansi. JPEG sama sekali tidak memiliki saluran alfa dalam spesifikasi format. Piksel transparan apa pun menjadi putih solid (atau apa pun yang diganti encoder Anda) saat Anda mengonversi PNG ke JPEG. Untuk logo, ikon, screenshot dengan latar belakang transparan, atau grafik apa pun dengan saluran alfa, tetap di PNG atau pindah ke WebP, yang keduanya mempertahankan transparansi.
• JPEG-ke-PNG membuat file lebih besar. Kompresi DEFLATE PNG hebat dalam gradien halus dan area solid besar, mengerikan pada pola kebisingan frekuensi tinggi yang ditinggalkan kompresi JPEG. Mengonversi JPEG ke PNG sering kali menggandakan atau melipatgandakan ukuran file tanpa peningkatan kualitas. Jika Anda membutuhkan lossless dari JPEG, Anda sudah terlambat: informasi asli sudah hilang. Konversi hanya masuk akal jika Anda secara khusus membutuhkan transparansi PNG atau alat yang tidak akan menerima JPEG.
• Metadata EXIF dilepas secara default. Library browser-image-compression secara default membuang metadata EXIF (info kamera, koordinat GPS, tanggal pengambilan, profil warna ICC) selama rekompresi. Untuk penggunaan web itu biasanya fitur (koordinat GPS yang bocor adalah masalah privasi nyata). Untuk fotografer mengarsipkan dengan metadata utuh, alat ini tidak tepat; gunakan kompresor desktop seperti ImageOptim atau jpegtran dengan flag preserve metadata eksplisit.
• Profil warna mungkin tidak bertahan. Profil warna ICC yang disematkan (sRGB, Adobe RGB, ProPhoto) memberi tahu tampilan cara menafsirkan nilai piksel. Pengkodean ulang berbasis Canvas dapat membuang profil yang disematkan dan menandai output sebagai sRGB. Untuk penggunaan layar biasa ini baik-baik saja karena hampir semuanya adalah sRGB. Untuk pekerjaan prep cetak, prep foto color-managed, atau deliverables wide-gamut, gunakan alat sadar-warna (Export As Photoshop, Affinity, RawTherapee) yang secara eksplisit mempertahankan data profil.
• Gambar yang sangat besar dapat merusak tab browser seluler. Mendekode gambar ke Canvas membutuhkan RAM proporsional dengan dimensinya: foto 24 megapiksel (6000x4000 piksel) membutuhkan sekitar 96 MB hanya untuk buffer piksel RGBA, ditambah memori kerja untuk encoder. Perangkat seluler dengan RAM 4 GB mungkin memiliki tab dihentikan oleh OS sebelum encode selesai. Ubah ukuran input atau gunakan browser desktop untuk foto yang sangat besar.

Privasi: gambar tetap di perangkat Anda

Setiap kompresor gambar cloud (TinyPNG, Compressor.io, Optimizilla, alat gambar Smallpdf, endpoint compress Pixlr, lusinan layanan kompres gambar online) mengunggah file Anda ke server operator, menjalankan algoritma kompresi mereka, dan mengembalikan gambar yang lebih kecil sebagai unduhan. Implikasi privasi tidak sepele karena foto rutin berisi konten yang dapat diidentifikasi: wajah, alamat yang terlihat di latar belakang, screenshot UI internal atau dokumen rahasia, foto anak-anak, foto yang diambil di ruang pribadi. Sebagian besar operator menerbitkan kebijakan privasi yang berkomitmen untuk menghapus unggahan dalam satu atau dua jam dan untuk mengenkripsi dalam transit, dan yang lebih besar (TinyPNG, Smallpdf) memegang sertifikasi ISO/IEC 27001. Mereka memiliki alasan komersial yang kuat untuk menghormati kebijakan tersebut. Tetapi dihapus dalam satu jam bukanlah tidak pernah dilihat. Selama jam itu konten gambar berada di infrastruktur operator, dapat diakses oleh proses atau orang mana pun dengan akses yang sesuai, dan terlihat dalam log dan cadangan sesuai dengan kebijakan retensi apa pun yang berlaku.

Kompresor ini tidak pernah mengunggah apa pun. Library browser-image-compression berjalan sepenuhnya di tab Anda; byte gambar dibaca oleh File API, diproses dalam JavaScript (atau dalam Web Worker jika OffscreenCanvas tersedia), dan output terkompresi dikembalikan ke tab yang sama sebagai Blob yang dapat diunduh. Anda dapat memverifikasi tidak ada unggahan dengan membuka alat pengembang browser ke tab Network sebelum mengompres batch: tidak ada permintaan yang menyala yang menyertakan konten gambar Anda. Satu-satunya lalu lintas jaringan adalah fetch library satu kali (~95 KB) dari CDN pada kunjungan pertama, setelah itu library di-cache. Alihkan browser ke mode pesawat setelah halaman dimuat dan kompresor terus bekerja pada file lokal. Untuk foto dengan apa pun yang sensitif (wajah, lokasi, screenshot internal), perdagangan sisi browser jelas sepadan dengan dilakukan.

Saat alat lain adalah pilihan yang tepat

• Memproses batch 500+ gambar dalam pipeline yang diskripkan. Gunakan sharp di Node.js (library gambar sisi server kanonik), ImageMagick atau GraphicsMagick di baris perintah, atau Pillow di Python. Alat-alat ini menangani ribuan file tanpa batas memori browser dan berjalan dari pekerjaan CI, hook penerapan, atau tugas cron.
• Jaminan lossless ketat dengan kesetaraan bit yang dapat diverifikasi. Untuk PNG-ke-PNG, alat ini benar-benar lossless karena UZIP tidak menyentuh data piksel. Untuk alur kerja yang menuntut verifikasi kriptografi (pencitraan medis, bukti hukum), gunakan alat desktop seperti ImageMagick dengan `-define png:compression-level=9` eksplisit dan verifikasi SHA-256 dari data piksel yang didekode.
• Pelestarian profil warna kelas cetak. Adobe Photoshop, Affinity Photo, atau RawTherapee untuk pekerjaan prep cetak dengan pelestarian profil ICC, soft-proofing, dan output CMYK. Kompresi berbasis browser tidak dapat menjamin alur kerja color-managed karena Canvas beroperasi dalam sRGB dan dapat menghapus data profil yang disematkan.
• Output AVIF untuk kompresi generasi berikutnya. browser-image-compression tidak menghasilkan AVIF pada tahun 2026. Untuk pengkodean AVIF di browser, gunakan Squoosh (juga Google, juga sisi klien); untuk AVIF baris perintah, gunakan avifenc dari libavif. AVIF menghasilkan file sekitar 50% lebih kecil dari JPEG pada kualitas yang sebanding, tetapi encoder mahal secara komputasi (10x lebih lambat dari pengkodean JPEG).

Pertanyaan yang Sering Diajukan

Apakah kompresi mengurangi kualitas gambar?

Pada kualitas default 60%, sebagian besar gambar terlihat hampir sama dengan aslinya sementara ukurannya 50-80% lebih kecil. Sesuaikan slider untuk menemukan keseimbangan yang tepat untuk kebutuhan Anda.

Apakah ada batas ukuran file?

Setiap gambar dapat berukuran hingga 50 MB. Karena pemrosesan terjadi di browser Anda, file yang sangat besar mungkin membutuhkan waktu tergantung pada perangkat Anda.

Apakah gambar saya diunggah ke server?

Tidak. Semua kompresi terjadi secara lokal di browser Anda. Gambar Anda tidak pernah meninggalkan perangkat Anda, membuatnya sepenuhnya privat dan aman.

Pengaturan kualitas apa yang harus saya gunakan?

Untuk penggunaan web, 60-70% ideal. Untuk cetak atau portofolio, coba 80-90%. Untuk kompresi maksimum (thumbnail, email), 30-50% bekerja dengan baik.

Pertanyaan umum lainnya

Mengapa output PNG saya hanya sedikit lebih kecil dari yang asli?

PNG itu lossless. Penghematan datang sepenuhnya dari menemukan kompresi DEFLATE yang lebih ketat dari data piksel yang sama, yang biasanya menghemat 5-25% dari yang ditulis alat authoring (Photoshop, Sketch, Figma) secara default. Jika PNG Anda sudah dioptimalkan dengan baik, tidak ada banyak ruang yang tersisa. Untuk mendapatkan pengurangan tambahan yang berarti, baik konversi ke WebP (yang mempertahankan transparansi dan biasanya 25% lebih kecil dari PNG) atau terima beberapa kerugian dengan mengonversi ke JPEG (yang bisa jauh lebih kecil tetapi menjatuhkan transparansi).

Apakah alat ini berfungsi offline?

Setelah kunjungan pertama, ya. Library browser-image-compression (sekitar 95 KB minified) di-cache oleh browser pada beban pertama. Kunjungan selanjutnya ke kompresor bekerja sepenuhnya offline, selama cache browser belum dibersihkan dalam sementara waktu. Anda dapat memverifikasi dengan mengaktifkan mode pesawat setelah membuka halaman sekali dan mengompres gambar lokal.

Akankah data EXIF saya (kamera, GPS, tanggal pengambilan) dipertahankan?

Tidak, metadata EXIF dihapus selama kompresi secara default. Untuk berbagi web ini biasanya diinginkan (koordinat GPS dan nomor seri kamera seharusnya tidak bocor), tetapi untuk fotografer yang mengarsipkan dengan metadata utuh, alat ini tidak tepat. Gunakan kompresor sadar EXIF desktop seperti ImageOptim (macOS) atau jpegtran dengan opsi `-copy all` untuk mempertahankan metadata.

Apa perbedaan antara resize Lebar Maks dan pengurangan kualitas?

Mengubah ukuran mengubah dimensi piksel gambar: foto 4000x3000 yang diubah ukurannya menjadi 1920x1440 memiliki 75% lebih sedikit piksel untuk dikodekan, yang memotong ukuran file sebelum kompresi apa pun bahkan berjalan. Pengurangan kualitas (slider) mengontrol seberapa agresif encoder JPEG atau WebP membulatkan koefisien DCT-nya, yang membuat data yang dikodekan lebih kecil per piksel. Keduanya bertumpuk: ubah ukuran dulu untuk menjatuhkan jumlah piksel total, kemudian kurangi kualitas dari sisanya. Untuk alur kerja tipikal jadikan ini ramah-web, atur lebar maks 1920, kualitas 70, dan outputnya kira-kira 10-15% dari ukuran asli.

Bisakah saya mengompres gambar HEIC dari iPhone saya?

Dukungan browser untuk mendekode HEIC terbatas (Safari pada perangkat Apple melakukannya; Chrome dan Firefox tidak). Pada browser non-Apple, alat ini akan menolak file HEIC. Alur kerja untuk foto iPhone adalah baik mengubah pengaturan iPhone (Kamera → Format → Paling Kompatibel) untuk menyimpan JPEG secara langsung, atau mengonversi HEIC ke JPEG sekali di Mac atau dengan alat khusus, kemudian menjalankan JPEG itu melalui kompresor ini. Lembar Bagikan via iCloud biasanya mengonversi ke JPEG secara otomatis saat berbagi ke penerima non-Apple.

Apakah ada padanan desktop atau baris perintah?

Beberapa. Untuk otomasi batch, sharp di Node.js adalah library sisi server standar dan menghasilkan output yang hampir identik. ImageMagick (magick input.jpg -quality 70 output.jpg) dan GraphicsMagick menangani file besar dan berjalan dari shell apa pun. jpegoptim dan optipng adalah pengkode ulang JPEG dan PNG khusus yang sering memeras beberapa persen ekstra dibandingkan alat generik. Untuk pekerjaan interaktif sekali pakai seperti alat ini tetapi dengan lebih banyak kontrol, Squoosh (Google Chrome Labs, juga sepenuhnya sisi klien) mendukung berbagai format termasuk AVIF.

Alat Terkait