Base64-এ এনকোড করুন
টেক্সট, একটি ছবি বা যেকোনো ফাইল — সঠিকভাবে Base64-এ রূপান্তর। অ্যাকসেন্টযুক্ত অক্ষর ও ইমোজি অক্ষত থাকে, যা সাধারণ এক লাইনের ইমপ্লিমেন্টেশনগুলো পারে না। কিছুই সংরক্ষণ করা হয় না।
- কখনো সংরক্ষণ করা হয় না
- কোনো লাইন নেই, অপেক্ষা নেই
- সাইনআপ নেই, ওয়াটারমার্ক নেই
টেক্সট UTF-8 হিসেবে এনকোড হয়, তাই যুক্তবর্ণ, বিশেষ চিহ্ন ও ইমোজি অক্ষত থাকে।
Base64 এখানে দেখা যাবে।
যেভাবে কাজ করে
টেক্সট পেস্ট করুন বা ফাইল ছাড়ুন
টেক্সট UTF-8 হিসেবে এনকোড হয়। ফাইল বাইট ধরে ধরে এনকোড হয়, আর কখনো সংরক্ষণ করা হয় না।
ধরন বেছে নিন
স্ট্যান্ডার্ড Base64, টোকেন ও কোয়েরি স্ট্রিংয়ের জন্য URL-নিরাপদ Base64URL, অথবা CSS বা <img> ট্যাগে পেস্ট করার জন্য তৈরি পূর্ণ data URI।
কপি করুন
ফলাফল কপি করুন, অথবা বড় হলে টেক্সট ফাইল হিসেবে ডাউনলোড করুন।
কেন ঠিক এক-তৃতীয়াংশ বড় হয়
Base64 একবারে তিনটি বাইট নিয়ে চারটি অক্ষরে লেখে, যার প্রতিটি চব্বিশ বিটের ছয়টি করে বহন করে। চারকে তিন দিয়ে ভাগ করলেই আসে বিখ্যাত ৩৩ শতাংশ — এটা পাটিগণিত, অদক্ষতা নয়, আর প্রিন্টযোগ্য অক্ষরের সীমার মধ্যে থেকে কোনো এনকোডার এর চেয়ে ভালো করতে পারে না। ডেটা তিন দিয়ে সমানভাবে ভাগ না হলে শেষ গ্রুপটি প্যাড করে একটি বা দুটি = চিহ্ন দেওয়া হয়, এ কারণেই যেকোনো base64 স্ট্রিংয়ের দৈর্ঘ্য সবসময় চারের গুণিতক।
অক্ষরমালা দুটি, আর ভুলটি বেছে নেওয়াই এখানে মানুষের আনা সবচেয়ে সাধারণ সমস্যা। স্ট্যান্ডার্ড অক্ষরমালা শেষ হয় + ও / দিয়ে, আর দুটিরই URL-এ অর্থ আছে — কোয়েরি স্ট্রিংয়ে প্লাস হয়ে যায় স্পেস, আর স্ল্যাশকে পাথের বিভাজক মনে হয়। URL-নিরাপদ রূপে এর বদলে - ও _ ব্যবহার হয়, আর JSON Web Token, ফাইলের নাম এবং ঠিকানায় থাকা যেকোনো কিছুতে এটাই চলে। বাকি সব দিক থেকে দুটি হুবহু এক, আর একটিতে এনকোড করা মান অন্যটি হিসেবে ডিকোড করলে এমনভাবে ব্যর্থ হয় যে দেখে ডেটা নষ্ট হয়েছে মনে হয়।
প্রসঙ্গ অনুযায়ী বদলানো আরেকটি বিষয় হলো লাইন র্যাপিং। ইমেইল অ্যাটাচমেন্টে ৭৬ অক্ষরের লাইন লাগে, PEM সার্টিফিকেট ও কি-তে ৬৪, আর data URI বা JSON ফিল্ডে কোনো লাইন ব্রেকই চলে না। এখানে এটি ডিফল্টভাবে বন্ধ, কারণ এখন র্যাপ ছাড়াটাই বেশি প্রচলিত; গন্তব্য যখন ইমেইল হেডার বা একটি -----BEGIN----- ব্লক, তখন চালু করুন, কারণ সেগুলো একটিমাত্র বিশাল লাইন প্রত্যাখ্যান করে।
Base64 এনক্রিপশন নয়, আর এটি কোনো সুরক্ষাই দেয় না। এটি শুধু অক্ষরমালার বদল — যে কেউ সঙ্গে সঙ্গে উল্টে দিতে পারে, আর যেকোনো সিকিউরিটি স্ক্যানার তা স্বয়ংক্রিয়ভাবেই করে। এর উদ্দেশ্য হলো বাইনারি ডেটাকে এমন পথে পাঠানো, যা শুধু টেক্সট গ্রহণ করে: ইমেইলের বডি, JSON ফিল্ড, XML ডকুমেন্ট, স্টাইলশিটের data URI। কনফিগারেশনে পাসওয়ার্ড লুকাতে এটি ব্যবহার করলে, যে একবার তাকায় তার কাছ থেকে কিছুই আড়াল হয় না।
অন্য কিছু দরকার হলে
কমান্ড লাইনে Linux-এ base64 -w 0 file.bin র্যাপ ছাড়া এনকোড করে, আর macOS-এ সাধারণ base64 একই কাজ করে, অন্যদিকে openssl base64 -A সব জায়গায় একইভাবে চলে। URL-নিরাপদ অক্ষরমালার জন্য basenc --base64url অক্ষর বদলানোর আলাদা ধাপ ছাড়াই ঠিকভাবে কাজটি করে।
বড় ফাইলের জন্য এখানকার সবকিছুই ভুল পদ্ধতি — পুরো ফাইল মেমরিতে রাখা হয়, আর অন্য কিছু হওয়ার আগেই এনকোডিং সেটিকে এক-তৃতীয়াংশ বাড়িয়ে দেয়। কমান্ড-লাইন টুলগুলো এর বদলে স্ট্রিম করে, আর কোডে প্রতিটি ভাষাতেই ধাপে ধাপে এনকোড করার ব্যবস্থা আছে। আদৌ base64 দরকার কি না, সেটাও ভেবে দেখা ভালো: বাইনারি multipart/form-data হিসেবে বা সরাসরি বডি হিসেবে পাঠালে মেমরির সমস্যা আর ৩৩ শতাংশ — দুটোই এড়ানো যায়।
সাধারণ প্রশ্নোত্তর
আমার টেক্সট বা ফাইল কি কোথাও সংরক্ষণ করা হয়?
না। কিছুই সংরক্ষণ করা হয় না, কিছুই লগ করা হয় না, আর কোনো সার্ভার কখনো এটি দেখে না — নেটওয়ার্ক বিচ্ছিন্ন থাকলেও এটি কাজ করতে থাকে। বিশেষ করে এই টুলগুলোর জন্য এটা শুধু বাড়তি সুবিধা নয়। অনলাইন এনকোডার ও ডিকোডারে মানুষ যা পেস্ট করে, তা প্রায়ই সচল জিনিস: সেশন টোকেন, API কি, Authorization হেডার, গ্রাহকের তথ্য। এর একটিও এমন পেজে পেস্ট করা, যা সেটি কোথাও পাঠায়, মানে তা ফাঁস করে দেওয়া — সাইট মুছে ফেলার ব্যাপারে যে প্রতিশ্রুতিই দিক না কেন।
এখানে অ্যাকসেন্টযুক্ত অক্ষর ও ইমোজি কেন কাজ করে?
কারণ এনকোড করার আগে টেক্সটকে UTF-8 বাইটে রূপান্তর করা হয়, যা সঠিক ক্রম, আর বেশিরভাগ তাড়াহুড়োর ইমপ্লিমেন্টেশন এই ধাপটি বাদ দেয়। ব্রাউজারের নিজস্ব `btoa` টেক্সট নিতেই পারে না — এটি প্রতি অক্ষরে একটি বাইট নেয়, তাই `btoa("café")` সরাসরি ত্রুটি দেয়। বহুল প্রচলিত বিকল্প `btoa(unescape(encodeURIComponent(s)))` কাকতালীয়ভাবে কাজ করে, আর ইমোজি ও বেসিক রেঞ্জের বাইরের অক্ষরে ভেঙে পড়ে। এই পেজ UTF-8 ঠিকভাবে, একবারই এনকোড করে, তাই 日本語 ও 🎉 অক্ষত থাকে এবং ডিকোড করলে হুবহু ফিরে আসে।
Base64URL কী, আর কখন এটি দরকার?
এটি দুটি অক্ষর বদলানো Base64: + হয় -, / হয় _, আর শেষের = প্যাডিং বাদ দেওয়া হয়। এটি আছে কারণ +, / ও = — তিনটিরই URL-এ অর্থ আছে, তাই সাধারণ Base64 কোয়েরি স্ট্রিং বা পাথে গেলে বিকৃত হয়ে যায়। JWT, OAuth টোকেন আর URL-এ থাকা যেকোনো কিছু Base64URL ব্যবহার করে। ফলাফলটি লিংকে বসালে এটিই বেছে নিন।
Base64 কি কিছু এনক্রিপ্ট বা সুরক্ষিত করে?
না, আর এ বিষয়ে সোজাসাপ্টা বলাই ভালো। Base64 একটি এনকোডিং, এনক্রিপশন নয় — এতে কোনো কি নেই, কোনো গোপন কিছু নেই। স্ট্রিংটি যে দেখবে, সে-ই এক ধাপে ডিকোড করতে পারে, এই সাইটেও। এর কাজ হলো বাইনারি ডেটাকে এমন পথে নিরাপদে বহন করা, যা শুধু টেক্সট গ্রহণ করে, যেমন ইমেইল অ্যাটাচমেন্ট ও data URI। কিছু গোপন রাখতে হলে এনক্রিপশন লাগবে; Base64 কোনো সুরক্ষাই দেয় না।
Base64 আমার ফাইলের চেয়ে বড় কেন?
প্রায় ৩৩% বড়, সবসময়। Base64 প্রতি ৩ বাইটকে ৪টি টেক্সট অক্ষরে প্রকাশ করে, তাই নকশাগতভাবেই সাইজ এক-তৃতীয়াংশ বাড়ে, সঙ্গে সামান্য প্যাডিং। বাইনারিকে টেক্সটে রূপান্তরের এটাই মূল্য, আর এ কারণেই বড় একটি ছবি data URI হিসেবে CSS-এ বসানো সাধারণত লোকসানের সওদা।
কোনো ছবিকে কি data URI হিসেবে এনকোড করা যায়?
হ্যাঁ — ছবিটি ছাড়ুন আর data URI বেছে নিন। সঠিক মিডিয়া টাইপ বসানো পুরো `data:image/png;base64,…` স্ট্রিংটি পাবেন, স্টাইলশিট, <img> ট্যাগ বা ইমেইল টেমপ্লেটে পেস্ট করার জন্য তৈরি।
সাইজের কোনো সীমা আছে কি?
সীমা আপনার ডিভাইসের মেমরি, কোনো নির্দিষ্ট সাইজ নয়, আর তা যথেষ্ট উদার — অনেক মেগাবাইটের ফাইলও ঠিকঠাক এনকোড হয়। বড় ফাইল সামলানোর জন্যই এনকোডিং খণ্ডে খণ্ডে করা হয়; সহজ ইমপ্লিমেন্টেশন প্রায় ১২৫ KB-তে গিয়ে “Maximum call stack size exceeded” দেখিয়ে ক্র্যাশ করে, আর এটি বহু অনলাইন এনকোডারের একটি বাগ।
জেনে রাখুন: Base64 ডেটাকে প্রায় ৩৩% বড় করে — এটা ফরম্যাটের স্বভাব, কোনো ত্রুটি নয়। ফাইল পুরোটা একসাথে মেমরিতে পড়া হয়, তাই খুব বড় ফাইলে শেষ হওয়ার আগেই ফোনের ট্যাবের মেমরি ফুরিয়ে যেতে পারে। লাইন র্যাপিং ডিফল্টভাবে বন্ধ থাকে; ইমেইল ও PEM ফরম্যাটে এটি চালু থাকা দরকার।
এই টুলটি আপনার ওয়েবসাইটে যোগ করুন
যেকোনো ব্লগ, ক্লাসের পেজ বা হেল্প আর্টিকেলের জন্য ফ্রি। একটি স্নিপেট পেস্ট করলেই আপনার ভিজিটররা আপনার পেজেই এটি ব্যবহার করতে পারবেন।