Enkode atau dekode Base64, Base64URL, URL percent-encoding, entitas HTML, dan hex saat Anda mengetik, dengan dukungan UTF-8 penuh.
Tidak ada yang Anda masukkan disimpan - dikonversi dan dikembalikan dalam permintaan yang sama.
Token di log, query string di redirect, email penuh &: teks yang di-encode muncul di mana-mana di tempat kerja. Tempel di sini, pilih formatnya, dan lihat hasil encode atau decode saat Anda mengetik.
JSON Web Token terdiri dari tiga bagian Base64URL yang digabung dengan titik: header, payload, dan signature. Tempel bagian tengahnya, pilih Base64URL lalu decode, dan Anda melihat klaim JSON seperti id pengguna dan waktu kedaluwarsa exp (timestamp Unix yang bisa dibaca dengan Konverter timestamp Unix). Decode bukan verifikasi: siapa pun bisa membaca payload JWT, dan hanya pemeriksaan signature di server yang membuktikan isinya tidak diubah.
Base64 yang padding-nya dibuang, yang dilakukan sebagian sistem untuk menghemat ruang, gagal di decoder yang ketat; alat ini menambahkan tanda = yang hilang dan memberi tahu Anda. Banyak server membaca + di query string sebagai spasi, sehingga nilai Base64 yang ditempel ke tautan tanpa di-encode tiba dalam keadaan rusak; encode sebagai komponen URL atau gunakan Base64URL. Teks yang di-encode dua kali muncul sebagai %2520 atau & dan perlu di-decode dua kali.
Decode Base64 mengabaikan spasi dan baris baru, jadi nilai yang terpotong menjadi beberapa baris, seperti di email, didekode apa adanya saat ditempel. Decode Base64URL juga menerima + dan /, tetapi Base64 biasa menolak - dan _, jadi bagian JWT memerlukan opsi Base64URL. Decode hex melewati spasi, titik dua, koma, tanda hubung, dan awalan 0x, jadi 48:65:6c:6c:6f maupun 0x48 0x65 sama-sama berhasil. Decode URL mengubah + menjadi spasi, jadi tanda plus yang sebenarnya harus dikirim sebagai %2B. Encode HTML meng-escape lima karakter & < > " dan '; decode HTML memahami semua entitas bernama HTML5, seperti dan …, serta entitas numerik seperti ₹ untuk simbol rupee.
Encoding URL di sini mengodekan satu nilai, misalnya satu parameter query, jadi setiap karakter khusus di-escape: https://example.com/a b?x=1&y=2 menjadi https%3A%2F%2Fexample.com%2Fa%20b%3Fx%3D1%26y%3D2. Kodekan hanya nilai yang Anda sisipkan ke tautan, jangan seluruh tautannya. Teks di luar ASCII dikodekan sebagai byte UTF-8-nya: café ₹ menjadi caf%C3%A9%20%E2%82%B9, dan hex menampilkan byte yang sama, é sebagai c3 a9 dan ₹ sebagai e2 82 b9. Base64 dari user:pass adalah dXNlcjpwYXNz, nilai yang dibawa header HTTP Basic Authorization (RFC 7617), sehingga siapa pun yang melihat header itu bisa membaca kata sandinya.
Byte-nya UTF-8, tetapi di suatu tempat dibaca sebagai Latin-1 atau Windows-1252 sebelum di-encode. Decode di sini menampilkan byte apa adanya; perbaikannya ada di sistem yang menghasilkannya.
Tempel teks hingga 200.000 karakter. Untuk file biner seperti gambar, byte hasil decode ditampilkan sebagai hex, bukan dijadikan unduhan.
Bukan. Base64 hanya mengubah cara byte ditulis agar lolos melewati sistem yang mengharapkan teks biasa. Siapa pun bisa men-decode-nya; jangan pernah memakainya untuk menyembunyikan kata sandi atau rahasia.
Base64URL mengganti "+" dan "/" dengan "-" dan "_" dan biasanya membuang padding "=", sehingga hasilnya aman di dalam URL dan nama file. JSON Web Token memakainya.
Tidak. Teks dikonversi dan dikembalikan dalam permintaan yang sama dan tidak pernah ditulis ke database atau log.
Alat ini juga meng-escape ! ' ( ) dan *, yang dibiarkan apa adanya oleh encodeURIComponent, jadi it's (50%) off! menjadi it%27s%20%2850%25%29%20off%21. Kedua bentuk didekode menjadi teks yang sama, dan meng-escape karakter itu selalu aman di dalam nilai query. Spasi menjadi %20, bukan +; bentuk + berasal dari encoding formulir HTML, dan dekoder di sini membaca keduanya.
Di Linux atau Mac, echo -n 'Hello, World' | base64 menghasilkan SGVsbG8sIFdvcmxk, dan echo 'SGVsbG8sIFdvcmxk' | base64 --decode mengembalikannya menjadi teks. Tanpa -n, echo menambahkan baris baru yang ikut dienkode sehingga hasilnya SGVsbG8sIFdvcmxkCg==: penyebab paling umum dua alat memberi hasil berbeda. Di PowerShell, [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Hello, World')) mengenkode dan [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('SGVsbG8sIFdvcmxk')) mendekode. Halaman ini mengenkode persis karakter yang Anda tempel, sebagai UTF-8, tanpa menambahkan baris baru.
Tempel hanya bagian setelah koma: pada data:image/png;base64,iVBORw0KGgo... bagian itu adalah iVBORw0KGgo..., karena awalan data:image/png;base64, bukan Base64 dan seluruh string akan ditolak. Pilih Base64 lalu Decode. Byte yang bukan teks ditampilkan sebagai hex, bukan digambar sebagai gambar, dan itu cukup untuk mengenali jenis file: PNG diawali 89 50 4e 47, JPEG ff d8 ff, dan file .docx, .xlsx atau file berbasis ZIP lain yang utuh 50 4b 03 04. Untuk melihat gambarnya, tempel data URI lengkap ke bilah alamat browser. Input dibatasi 200.000 karakter, sekitar 150.000 byte file.
Base64 menulis setiap 3 byte sebagai 4 karakter dan mengisi kelompok terakhir dengan = sampai kelipatan 4 (RFC 4648), jadi hasilnya 4/3 dari byte input, dibulatkan ke atas. Hello, World berukuran 12 byte dan menjadi 16 karakter SGVsbG8sIFdvcmxk. Yang dihitung adalah byte UTF-8, bukan huruf: café terdiri dari 4 karakter tetapi 5 byte dan menjadi Y2Fmw6k=, dan ₹100 berukuran 6 byte dan menjadi 4oK5MTAw. Lampiran email bertambah sedikit lagi karena MIME memecah Base64 menjadi baris paling panjang 76 karakter (RFC 2045); halaman ini mengabaikan pemisah baris itu saat mendekode. Base64URL tanpa padding hanya menghemat tanda =.