Mengapa Base64 membuat file lebih besar?

Artikel ini menjelaskan mengapa keluaran Base64 lebih besar daripada byte aslinya. Ini bukan panduan keamanan. Jika Anda perlu membedakan pengodean dan enkripsi, gunakan Base64 bukan enkripsi: apa yang sebenarnya dilakukannya.

Mengapa Base64 butuh ruang lebih?

3 byte adalah 24 bit. Base64 membagi 24 bit itu menjadi 4 kelompok 6 bit. Setiap kelompok dipetakan ke satu karakter Base64, jadi 3 byte masukan menjadi 4 karakter keluaran. Disimpan sebagai 1 byte per karakter ASCII, itu 4 / 3 ≈ 1.333 — kenaikan sekitar 33.3%.

• 3 byte (24 bit)
• ↓
• Dipisah menjadi 4 kelompok 6 bit
• Setiap kelompok → satu karakter Base64
• ↓
• 4 karakter (sering 4 byte teks)

Contoh sederhana yang bisa dicek

Pengodean ini cocok dengan Base64 berpadding standar.

Man

Man

Base64

TWFu

Man adalah 3 byte UTF-8/ASCII. TWFu adalah 4 karakter: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello adalah 5 byte. SGVsbG8= adalah 8 karakter, termasuk satu =. Pada data kecil, padding membuat persentase tampak lebih besar dari 33%.

Bagaimana menghitung ukuran Base64?

Untuk Base64 berpadding standar, encodedLength = 4 × ceil(originalBytes / 3).

Byte asli	Karakter Base64
1	4
2	4
3	4
4	8
5	8
6	8

1 atau 2 byte tetap menghasilkan 4 karakter. Pakai rumus, bukan 33% tetap.

Apa arti padding “=”?

Tanda = menunjukkan blok 3 byte terakhir tidak penuh. 1 byte masukan memakai dua =; 2 byte memakai satu; 3 byte tidak memakai. Padding bukan enkripsi dan bukan fitur keamanan.

Apakah Base64URL memakai ruang lebih sedikit?

Base64URL mengganti + menjadi - dan / menjadi _, dan Encode dan decode Base64 menghilangkan = di akhir saat encode. String bisa lebih pendek sebesar karakter = itu. Struktur 3 byte → 4 karakter tetap sama, jadi Base64URL bukan format biner yang lebih hemat ruang.

Mengapa masukan sangat kecil bisa tumbuh lebih dari 33%?

1 byte → 4 karakter adalah kenaikan panjang 300%. 2 byte → 4 adalah 100%. 3 byte → 4 sekitar 33.3%. Saat n membesar, padding semakin tidak terasa dan overhead mendekati sekitar 33%. Base64 tidak selalu tepat 33% lebih besar.

Mengapa Data URL Base64 bahkan lebih besar?

Data URL menambahkan awalan seperti data:image/png;base64, sebelum muatan. Pada file sangat kecil, awalan itu bisa mendominasi persentase. Encode dan decode Base64 dapat mengeluarkan Base64 mentah atau Data URL; keluaran Data URL memakai alfabet standar.

Base64 vs biner: mana yang lebih kecil?

Biner mentah lebih hemat ruang untuk transfer dan penyimpanan. Base64 lebih besar, tetapi aman sebagai teks di JSON, email, dan jalur hanya-teks lain. Ini pengodean biner-ke-teks, bukan kompresi.

Apakah Base64 mengompres file?

Tidak. Base64 bukan format kompresi. Teks hasil encode biasanya lebih besar daripada byte asli. Jika kemudian gzip atau Brotli diterapkan pada teks itu, sebagian redundansi bisa menyusut—hasilnya tergantung data dan kompresor. gzip tidak menghapus overhead Base64 secara universal.

Apa yang terjadi jika Base64 di-gzip?

Kompresi HTTP dapat mengurangi sebagian pola berulang dalam teks Base64. JPEG, PNG, atau ZIP sering sulit dikompres bahkan sebagai byte mentah, dan Base64 lalu gzip tetap tergantung kasus. Tidak ada persentase tambahan universal setelah gzip.

Haruskah file disimpan sebagai Base64?

Base64 bisa memasukkan biner ke kolom JSON, aset sebaris kecil, API hanya-teks, salin-tempel, atau Data URL. Untuk file besar, penyimpanan, memori, dan ukuran muatan semuanya tumbuh. Itu bukan “jangan pernah memakai Base64 untuk file.”

Mengapa Base64 umum di API JSON?

JSON tidak punya tipe biner mentah bawaan, jadi API sering menaruh byte dalam string Base64. Untuk file besar, multipart/form-data, object storage, atau unggahan biner langsung bisa lebih cocok. Tidak ada pilihan yang selalu terbaik.

Mengapa Base64 dipakai di email?

MIME dapat memakai Base64 agar lampiran biner berjalan sebagai karakter yang aman untuk teks. Overhead ukuran yang sama tetap berlaku. Ini representasi transport, bukan file yang lebih kecil.

Kapan tambahan ukuran itu sepadan?

Tambahan ukuran bisa sepadan ketika biner harus berada di dalam teks, muatannya kecil, API mensyaratkan Base64, atau Anda butuh Data URL. Untuk media besar, utamakan biner mentah jika sistem mengizinkan.

Kapan sebaiknya menghindari Base64?

Lewati untuk file besar, bandwidth ketat, transfer sering, atau ketika jalur biner sudah ada—itu situasional, bukan “Base64 adalah kebiasaan buruk.”

Panjang Base64 berpadding yang bisa dicek

Jumlah byte asli dan jumlah karakter Base64 berpadding standar:

Byte asli	Karakter Base64
1	4
2	4
3	4
10	16
100	136
1,000	1,336

Semua baris mengikuti 4 × ceil(n / 3). Ini adalah jumlah karakter Base64.

Contoh: seberapa besar file 1,000 byte?

4 × ceil(1000 / 3). ceil(333.333…) = 334, dan 4 × 334 = 1336. Jadi 1,000 byte menjadi 1,336 karakter Base64. Disimpan sebagai UTF-8/ASCII, setiap karakter biasanya 1 byte—jangan anggap 1,336 sebagai hitungan byte memori yang persis.

Bisakah Base64 memakai memori lebih dari ukuran file?

Beberapa runtime menyimpan string dengan lebih dari 1 byte per karakter, dan encode/decode dapat menahan buffer bersama string. Pemakaian memori tidak persis sama dengan panjang karakter.

Panduan keputusan ukuran yang sederhana

Jika sistem menerima biner mentah, utamakan itu demi ukuran. Jika hanya teks yang diizinkan, Base64 mungkin cocok. Untuk muatan besar, cek jalur unggah biner. Untuk teks aman URL, pertimbangkan Base64URL—perluasan 3-ke-4 tetap ada.

• Perlu mengirim data biner
• ↓
• Biner mentah diizinkan? Utamakan biner demi ukuran
• Kolom hanya-teks? Base64 mungkin tepat
• Muatan besar? Cek jalur unggah biner
• Butuh teks aman URL? Pertimbangkan Base64URL
• ↓
• Perkirakan teks sekitar 33% lebih banyak pada masukan besar

Encode atau dekode Base64 di browser Anda

NEXNARA Encode dan decode Base64 mengodekan dan mendekode teks, dan dapat mengubah file menjadi Base64 atau Data URL serta mengembalikan Base64 menjadi file.

Teks memakai byte UTF-8, lalu Base64—bukan hanya ASCII. Pilih Standard atau Base64URL. Keluaran file bisa Base64 mentah atau Data URL (alfabet standar). Masukan tidak valid ditolak. Byte non-UTF-8 perlu ke file, bukan dekode teks.

File di atas 10 MB dapat memperlambat tab (peringatan). File di atas 32 MB diblokir.

Pengodean dan dekode terjadi di browser Anda. File tidak dikirim ke server NEXNARA untuk alat ini. Iklan dan fitur situs lain tetap memakai jaringan.

Tempel teks atau file di Encode dan decode Base64 dan bandingkan byte asli dengan panjang hasil encode.

FAQ

Mengapa Base64 menambah ukuran file?

Ia memetakan 3 byte (24 bit) ke 4 karakter (4 × 6 bit). Disimpan sebagai teks, itu sekitar sepertiga lebih banyak untuk masukan besar.

Apakah Base64 selalu 33% lebih besar?

Tidak. Masukan besar mendekati sekitar 33.3%. Masukan sangat kecil bisa tumbuh lebih karena padding. Pakai 4 × ceil(n / 3).

Seberapa lebih besar Base64 dibanding biner?

Panjang berpadding standar adalah 4 × ceil(n / 3) karakter. Awalan Data URL menambah lagi.

Apakah kompresi Base64 mengurangi ukuran file?

Base64 tidak mengompres. Gzip atau Brotli pada teks hasil encode dapat menyusutkan sebagian; keduanya tidak menghapus overhead di setiap kasus.

Apakah Base64URL memakai ruang lebih sedikit?

Ia dapat membuang padding =, jadi string mungkin 0–2 karakter lebih pendek. Struktur pengodean 3-ke-4 tetap sama.

Haruskah saya memakai Base64 untuk file besar?

Hanya jika Anda butuh teks. Untuk transfer besar atau sering, jalur biner sering lebih kecil. Base64 tidak selalu salah untuk API.