Base64 এনকোড / ডিকোড

এক ক্লিকে টেক্সট ও ফাইল Base64-এ ও থেকে রূপান্তর করুন।

URL-safe Wrap Decode as

Text 0 bytes

Base64

0 bytes

Files & images As data URI

Drop a file or image here, click to browse — or paste an image (⌘/Ctrl-V) Everything is processed on your device. Large files use more memory.

Runs entirely in your browser. Nothing is uploaded.

একটি সম্পূর্ণ Base64 টুলকিট যা কখনও আপনার ব্রাউজার ছাড়ে না

Base64 বাইনারি ডেটাকে সাধারণ ASCII টেক্সটে রূপান্তরিত করে, যাতে তা টেক্সটের জন্য তৈরি সিস্টেমের মধ্য দিয়ে নিরাপদে চলাচল করতে পারে — ইমেইল বডি, JSON পেলোড, URL, HTML এবং CSS। এই টুলটি টেক্সট এবং ফাইল উভয়ের জন্যই Base64 এনকোড এবং ডিকোড করে, এবং বেশিরভাগ জনপ্রিয় Base64 ওয়েবসাইটের বিপরীতে এটি সম্পূর্ণভাবে আপনার ডিভাইসে চলে। আপনি যা পেস্ট বা ড্রপ করেন তা কখনও আপলোড হয় না, যা গুরুত্বপূর্ণ হয়ে ওঠে যখন ডেটাটি একটি অ্যাক্সেস টোকেন, একটি API কী, বা এমন কিছু যা আপনি কোনো থার্ড-পার্টি সার্ভারকে দিতে চান না।

এটি এমন সব ক্ষেত্রে কাজ করার জন্য তৈরি যা সরল টুল ভুল করে ফেলে: সম্পূর্ণ ইউনিকোড (ইমোজি এবং নন-ল্যাটিন স্ক্রিপ্টসহ), URL-সেফ Base64URL, MIME এবং PEM লাইন র‍্যাপিং, এবং এমন টেক্সট ডিকোড করা যা মূলত নন-UTF-8 ক্যারেক্টার সেটে এনকোড করা হয়েছিল।

যেকোনো কিছু ডিকোড করুন — ক্যারেক্টার সেট নিয়ন্ত্রণ এবং একটি সহনশীল পার্সারসহ

পেস্ট করা Base64 প্রায়ই এলোমেলো হয়: ইমেইল র‍্যাপিং থেকে লাইন ব্রেক এসে যায়, টার্মিনালে শেষের = প্যাডিং হারিয়ে যায়, বা একটি সম্পূর্ণ data: URI হিসেবে আসে। ডিকোডার এসব স্বয়ংক্রিয়ভাবে পরিষ্কার করে দেয় — হোয়াইটস্পেস সরিয়ে, URL-সেফ ক্যারেক্টার গ্রহণ করে, প্যাডিং পুনরুদ্ধার করে, এবং data URI আনর‍্যাপ করে — আর যদি কিছু সত্যিই অবৈধ হয়, তবে চুপচাপ ব্যর্থ না হয়ে সঠিক ক্যারেক্টার এবং তার অবস্থান দেখিয়ে দেয়।

যেহেতু Base64 কোনো ক্যারেক্টার-সেট লেবেল ছাড়াই কাঁচা বাইট সংরক্ষণ করে, ডিকোড করা টেক্সট এলোমেলো দেখাতে পারে যদি সেটি মূলত UTF-8 হিসেবে তৈরি না হয়ে থাকে। Decode as নির্বাচক আপনাকে একই বাইটগুলোকে UTF-16, Latin-1, Windows-1252, ASCII, Shift_JIS বা GBK হিসেবে পুনর্ব্যাখ্যা করার সুযোগ দেয়। বাইনারি পেলোড ডিবাগ করার সময় কাঁচা বাইট সরাসরি পরিদর্শন করতে Hex ভিউতে সুইচ করুন।

ফাইল এবং ইমেজ, প্রিভিউ এবং রেডি-টু-পেস্ট স্নিপেটসহ

একটি ফাইল ড্রপ করুন, ব্রাউজ করতে ক্লিক করুন, বা আপনার ক্লিপবোর্ড থেকে শুধু একটি ইমেজ পেস্ট করুন। ইমেজগুলো ইনলাইনে প্রিভিউ হয়, এবং টুলটি ম্যাজিক বাইট থেকে ফাইলের ধরন শনাক্ত করে — তাই একটি ডিকোড করা ব্লবকে সঠিকভাবে PNG, JPEG, GIF, WebP, PDF ইত্যাদি হিসেবে চেনা যায়, এবং সঠিক এক্সটেনশনসহ ডাউনলোড হয়।

অ্যাসেট এমবেড করার জন্য, একটি ইমেজ এনকোড করুন এবং একটি রেডি-মেড data URI, একটি CSS background-image রুল, একটি <img> ট্যাগ, বা একটি ফেভিকন <link> কপি করুন — স্ট্রিংটি হাতে তৈরি করার দরকার নেই। ফেভিকন, ইমেইল লোগো বা আইকন স্প্রাইট একটি সিঙ্গেল-ফাইল পেজে ইনলাইন করার সময় ডেভেলপারদের ঠিক এটিই প্রয়োজন হয়।

কেন এটি অন্যান্য ফ্রি Base64 টুলের চেয়ে ভালো

অনেক ফ্রি Base64 টুল — জনপ্রিয় সাইট যেমন base64decode.org এবং base64encode.org সহ — আপনার ইনপুট সার্ভার-সাইডে প্রসেস করে। এর মানে আপনার JWT টোকেন, API কী এবং প্রাইভেট ফাইল কনটেন্ট একটি রিমোট সার্ভারে পাঠানো হয় যা আপনার নিয়ন্ত্রণে নেই। UtiloKit-এর Base64 টুল আপনার ব্রাউজারে ১০০% JavaScript-এ চলে। পেজ লোড হওয়ার পর আপনি ইন্টারনেট থেকে সংযোগ বিচ্ছিন্নও করতে পারেন এবং এটি নিখুঁতভাবে কাজ করবে।

CyberChef চমৎকার কিন্তু সাধারণ এনকোডিং কাজের জন্য এর শেখার বক্ররেখা খাড়া। base64.guru টেক্সট ভালোভাবে হ্যান্ডেল করে কিন্তু ফাইল তাদের সার্ভারে আপলোড করে। TinyWow ফ্রি ব্যবহারকারীদের ওপর দৈনিক সীমা আরোপ করে। UtiloKit ইমেইল সামঞ্জস্যের জন্য MIME লাইন-র‍্যাপিং, সার্টিফিকেটের জন্য PEM ফরম্যাটিং, আন্তর্জাতিক টেক্সটের জন্য ক্যারেক্টার-সেট-সচেতন ডিকোডিং, JWT এবং OAuth টোকেনের জন্য URL-সেফ Base64URL সমর্থন, এবং ডিকোড করা বাইনারির জন্য ফাইল টাইপ শনাক্তকরণ অফার করে — সবই ফ্রি, সবই আনলিমিটেড, সবই প্রাইভেট।

আইফোন, অ্যান্ড্রয়েড এবং যেকোনো ডিভাইসে কাজ করে — কোনো অ্যাপের দরকার নেই

এই Base64 এনকোডার এবং ডিকোডার সম্পূর্ণভাবে রেসপন্সিভ এবং আধুনিক ব্রাউজারযুক্ত প্রতিটি ডিভাইসে কাজ করে। আইফোন এবং অ্যান্ড্রয়েডে, আপনি সরাসরি ক্লিপবোর্ড থেকে টেক্সট পেস্ট করতে পারবেন, Files অ্যাপ বা ক্যামেরা রোল থেকে ফাইল বাছাই করতে পারবেন, এবং এনকোড বা ডিকোড করা ফলাফল ডাউনলোড করতে পারবেন — কিছু ইনস্টল না করেই। ইন্টারফেসটি ৩৭৫px প্রস্থ থেকে শুরু করে ছোট স্ক্রিনের জন্য অপ্টিমাইজড।

টুলটি একবার লোড হওয়ার পর সম্পূর্ণভাবে অফলাইনে চলার কারণে (কোনো সার্ভার কল নেই, কোনো ডিপেন্ডেন্সি নেই), এটি এমন পরিস্থিতিতেও কাজ চালিয়ে যায় যেখানে base64decode.org বা CyberChef-এর মতো ওয়েব-ভিত্তিক টুল সমস্যায় পড়তে পারে — VPN-এর ভেতরে, লোড হওয়ার পর এয়ারপ্লেন মোডে, বা সীমিত নেটওয়ার্ক অ্যাক্সেসযুক্ত একটি ডিভাইসে। মোবাইলে ডেভেলপাররা JWT পেলোড ডিকোড করতে পারেন, iOS-এ ইঞ্জিনিয়াররা data URI পরিদর্শন করতে পারেন, এবং যে কেউ ডেস্কটপ মেশিন ছাড়াই CSS-এ ইমেজ এমবেড করতে পারেন।

Base64 এনকোডিং কীভাবে কাজ করে: ধাপে ধাপে অ্যালগরিদম

Base64 ইনপুট বাইটগুলোকে তিন-বাইট গুচ্ছে ভাগ করে এবং প্রতিটি গুচ্ছকে চারটি প্রিন্টযোগ্য ক্যারেক্টারে রূপান্তরিত করে কাজ করে। প্রথমে, কাঁচা বাইটগুলোকে একটি অবিচ্ছিন্ন বিটস্ট্রিম হিসেবে সাজানো হয়। সেই স্ট্রিমের প্রতি ৬ বিট ৬৪-ক্যারেক্টার বর্ণমালার একটি ইনডেক্সে ম্যাপ হয়: বড় হাতের A–Z (ইনডেক্স ০–২৫), ছোট হাতের a–z (২৬–৫১), সংখ্যা ০–৯ (৫২–৬১), + (৬২), এবং / (৬৩)। যেহেতু ৬ বিট ৬৪টি মান উপস্থাপন করতে পারে এবং ৮ বিট ২৫৬টি মান, তিনটি ৮-বিট বাইট (২৪ বিট) এনকোড করলে সবসময় ঠিক চারটি ৬-বিট গুচ্ছ (আবারও ২৪ বিট) পাওয়া যায় — এবং চারটি প্রিন্টযোগ্য ক্যারেক্টার। এই স্থির ৩-থেকে-৪ রূপান্তর অনুপাতের কারণেই Base64 আউটপুট সবসময় ইনপুটের চেয়ে প্রায় ৩৩% বড় হয়।

একটি বাস্তব উদাহরণ অ্যালগরিদমটিকে স্পষ্ট করে তোলে। Man শব্দটি এনকোড করা শুরু হয় তার ASCII মান দিয়ে: M = ৭৭, a = ৯৭, n = ১১০। বাইনারিতে সেগুলো হলো 01001101 01100001 01101110। ২৪ বিট হিসেবে পাশাপাশি রাখা এবং চারটি ৬-বিট গুচ্ছে ভাগ করা: 010011 (১৯ → T), 010110 (২২ → W), 000101 (৫ → F), 101110 (৪৬ → u) — যা Base64 স্ট্রিং TWFu তৈরি করে। যখন মোট ইনপুট দৈর্ঘ্য ৩-এর গুণিতক না হয়, শেষ গুচ্ছটি শূন্য বিট দিয়ে প্যাড করে একটি সম্পূর্ণ ৬-বিট সীমায় পৌঁছানো হয়, এবং শেষ এনকোড করা গুচ্ছটি ছোট ছিল তা বোঝাতে এক বা দুটি = প্যাডিং ক্যারেক্টার যোগ করা হয়। একটি = মানে শেষ ইনপুট গুচ্ছে ২ বাইট ছিল; দুটি == মানে মাত্র ১ বাইট ছিল।

ডিকোডিং প্রক্রিয়াটি ঠিক উল্টো দিকে যায়: প্রতিটি ক্যারেক্টার তার ৬-বিট ইনডেক্স পুনরুদ্ধার করতে বর্ণমালায় খোঁজা হয়, চারটি গুচ্ছ একত্রিত করে ২৪ বিট তৈরি করা হয়, এবং সেই বিটগুলো আবার তিনটি বাইটে ভাগ করা হয়। প্যাডিং ক্যারেক্টার বাদ দেওয়া হয়। যেহেতু ম্যাপিংটি কোনো কী বা স্টেট ছাড়াই একটি সাধারণ লুকআপ টেবিল, ডিকোডিং তাৎক্ষণিক — কোনো গোপন কিছু আবিষ্কার করার নেই এবং ব্রুট-ফোর্স করার কিছু নেই। এই কারণেই Base64 শূন্য গোপনীয়তা প্রদান করে এবং এটিকে কখনও এনক্রিপশনের সাথে গুলিয়ে ফেলা উচিত নয়।

কেন Base64 আবিষ্কার হয়েছিল: SMTP, MIME, এবং ৭-বিট ASCII সমস্যা

Base64-এর প্রয়োজনীয়তার শেকড় ইন্টারনেট যখন তরুণ ছিল তখনকার সিদ্ধান্তে প্রোথিত। SMTP, ইমেইল প্রোটোকল, ১৯৮০-এর দশকের শুরুতে ৭-বিট ASCII টেক্সটের জন্য ডিজাইন করা হয়েছিল। মেইল সার্ভারগুলো বার্তা রিলে নোডের মধ্য দিয়ে পাঠাত যা প্রতিটি বাইটের ৮ম বিট বাদ দিত — টেলিগ্রাফ নেটওয়ার্ক থেকে উত্তরাধিকারসূত্রে পাওয়া একটি অভ্যাস। বাইনারি ফাইল, ইমেজ, এবং ১২৭-এর বেশি বাইট মান ব্যবহারকারী যেকোনো নন-ইংরেজি টেক্সট চলাচলের সময় নীরবে নষ্ট হয়ে যেত। কাঁচা বাইট দিয়ে ইমেইলে একটি ছবি বা একটি প্রোগ্রাম এক্সিকিউটেবল পাঠানো ছিল একেবারেই অসম্ভব।

MIME (Multipurpose Internet Mail Extensions), ১৯৯২ সালে RFC 2045-এ প্রমিতকৃত, কন্টেন্ট-ট্রান্সফার এনকোডিংয়ের একটি সেট সংজ্ঞায়িত করে এই সমস্যা সমাধান করে যা ASCII-শুধু ইনফ্রাস্ট্রাকচারের জন্য বাইনারি ডেটাকে নিরাপদ করে তোলে। Base64-কে যেকোনো বাইনারির জন্য MIME-এর এনকোডিং হিসেবে নির্দিষ্ট করা হয়েছিল কারণ এটি প্রতিটি বাইটকে নিরাপদ ৭-বিট ASCII পরিসরের ক্যারেক্টারে রূপান্তরিত করে, উচ্চ বিট বাদ দেয় এমন প্রতিটি মেইল রিলে থেকে বেঁচে থাকে। একই অন্তর্নিহিত সমস্যা — একটি টেক্সট-ভিত্তিক চ্যানেল যা যেকোনো বাইট নির্ভরযোগ্যভাবে বহন করতে পারে না — ওয়েব স্ট্যাকজুড়ে বারবার দেখা দেয়: HTTP হেডারে কাঁচা বাইট থাকতে পারে না, কুকিজ ASCII-এর একটি উপসেটে সীমাবদ্ধ, JSON এবং XML হলো টেক্সট ফরম্যাট যেখানে NUL বাইট বা আনএস্কেপড বাইনারি পার্সিং ভেঙে দেবে, এবং HTML অ্যাট্রিবিউটে আনএস্কেপড অ্যাঙ্গেল ব্র্যাকেট বা কোট থাকতে পারে না। Base64 এই সব সীমাবদ্ধতার সর্বজনীন উত্তর কারণ এটি যেকোনো বাইনারি সিকোয়েন্সকে এমন একটি স্ট্রিং-এ রূপান্তরিত করে যা যেকোনো টেক্সট-ভিত্তিক সিস্টেম কোনো পরিবর্তন ছাড়াই সংরক্ষণ এবং ফরওয়ার্ড করতে পারে।

আজ SMTP বেশিরভাগই ৮-বিট ক্লিন এবং অনেক ইমেইল সার্ভার 8BITMIME এক্সটেনশন সমর্থন করে, কিন্তু অ্যাটাচমেন্টের Base64 এনকোডিং টিকে আছে কারণ MIME স্ট্যান্ডার্ডটি প্রতিটি মেইল ক্লায়েন্ট এবং সার্ভারে গভীরভাবে এমবেডেড। ১৯৮০-এর দশকের ইমেইল ঠিক করা এনকোডিংটি এখন JWT, data URI, SSH কী, TLS সার্টিফিকেট, HTTP Basic Auth এবং আরও কয়েক ডজন আধুনিক স্ট্যান্ডার্ডে বোনা — সবই কারণ একই ৭-বিট নিরাপত্তা প্রয়োজনীয়তা নতুন প্রেক্ষাপটে বারবার ফিরে আসতে থাকে।

Base64 ভ্যারিয়েন্ট: স্ট্যান্ডার্ড, URL-সেফ, MIME এবং প্যাডিং-ফ্রি

একটিমাত্র Base64 নেই — বেশ কয়েকটি নিবিড়ভাবে সম্পর্কিত ভ্যারিয়েন্ট রয়েছে যা তাদের বর্ণমালার দুটি ক্যারেক্টারে এবং লাইন ব্রেক ও প্যাডিং কীভাবে হ্যান্ডেল করে তাতে ভিন্ন। স্ট্যান্ডার্ড Base64 (RFC 4648 §4) ৬২তম এবং ৬৩তম ক্যারেক্টার হিসেবে + এবং / ব্যবহার করে এবং = প্যাডিং প্রয়োজন। এটি MIME ইমেইল অ্যাটাচমেন্ট, PEM সার্টিফিকেট এবং বেশিরভাগ সাধারণ-উদ্দেশ্যের এনকোডিং লাইব্রেরিতে ব্যবহৃত ভ্যারিয়েন্ট। + এবং / ক্যারেক্টার অন্যত্র ঘর্ষণের উৎস।

URL-সেফ Base64 (RFC 4648 §5, Base64url নামেও পরিচিত) +-কে - দিয়ে এবং /-কে _ দিয়ে প্রতিস্থাপন করে। এটি গুরুত্বপূর্ণ কারণ URL কোয়েরি স্ট্রিংয়ে + মানে স্পেস এবং / হলো পাথ সেপারেটর — একটি URL-এ এমবেড করা স্ট্যান্ডার্ড Base64 স্ট্রিং ভুলভাবে ব্যাখ্যা হতো বা percent-encoding প্রয়োজন হতো, যা এটিকে দীর্ঘ এবং পড়া কঠিন করে তুলত। Base64url হলো JWT স্পেসিফিকেশন (RFC 7519), OAuth 2.0 PKCE, এবং এমন যেকোনো প্রেক্ষাপটে বাধ্যতামূলক ভ্যারিয়েন্ট যেখানে এনকোড করা স্ট্রিং একটি URL, ফাইলনেম বা HTTP হেডারে প্রদর্শিত হয়। JWT অতিরিক্তভাবে শেষের = প্যাডিং সম্পূর্ণভাবে বাদ দেয়, কারণ একটি JWT সেগমেন্টের দৈর্ঘ্য সামগ্রিক গঠন থেকে অনুমান করা যায়, এবং URL-এ প্যাডিং ক্যারেক্টারগুলোকে অন্যথায় %3D হিসেবে percent-encode করতে হবে।

MIME Base64 (RFC 2045) হলো স্ট্যান্ডার্ড Base64 প্রতি ৭৬ ক্যারেক্টারে একটি বাধ্যতামূলক লাইন ব্রেকসহ, CRLF (\r\n) ব্যবহার করে। এটি প্রয়োজন ছিল প্রাথমিক মেইল সিস্টেম দ্বারা আরোপিত ঐতিহ্যগত ৭৬-ক্যারেক্টার প্রস্থের মধ্যে ইমেইল লাইন রাখতে। PEM (X.509 সার্টিফিকেট এবং SSH কী-এর জন্য ব্যবহৃত ফরম্যাট) একই ৬৪-ক্যারেক্টার লাইন দৈর্ঘ্য ব্যবহার করে -----BEGIN CERTIFICATE------এর মতো হেডারসহ। বিভিন্ন সিস্টেমের মধ্যে ইন্টারঅপারেট করার সময়, ভ্যারিয়েন্টটি গুরুত্বপূর্ণ: একটি স্ট্যান্ডার্ড ডিকোডারে দেওয়া একটি URL-সেফ স্ট্রিং - এবং _ ক্যারেক্টারে ব্যর্থ হবে, এবং লাইন ব্রেক না সরানো একটি ডিকোডারে দেওয়া একটি MIME-র‍্যাপড স্ট্রিং লাইন ব্রেকে ব্যর্থ হবে। একটি শক্তিশালী ডিকোডার — এই টুলের মতো — সব ভ্যারিয়েন্ট স্বয়ংক্রিয়ভাবে স্বাভাবিক করে দেয়।

যেখানে Base64 বাস্তবে দেখা যায় — এবং কেন এটি এনক্রিপশন নয়

বেশিরভাগ ডেভেলপারের ধারণার চেয়ে Base64 অনেক বেশি জায়গায় এমবেডেড। JWT (JSON Web Token) তাদের হেডার এবং পেলোড উভয়কেই Base64url হিসেবে এনকোড করে — যেকোনো JWT একটি ডিকোডারে পেস্ট করুন এবং আপনি সাথে সাথেই plain text-এ claim (ইউজার আইডি, রোল, মেয়াদ) পড়তে পারবেন। সিগনেচার টেম্পারিং প্রতিরোধ করে, কিন্তু পেলোড এনক্রিপ্ট করা নয়; যে কেউ একটি JWT ইন্টারসেপ্ট করলে তার ভেতরের সবকিছু পড়তে পারে। HTTP Basic Authentication username:password-কে Base64 হিসেবে এনকোড করে এবং Authorization হেডারে পাঠায় — প্লেইন HTTP-তে এটি সম্পূর্ণভাবে অনিরাপদ কারণ পাসওয়ার্ডটি সহজেই পুনরুদ্ধারযোগ্য। Basic Auth শুধুমাত্র HTTPS-এ নিরাপদ, যেখানে TLS হেডারসহ পুরো রিকোয়েস্ট এনক্রিপ্ট করে।

Data URI (src="data:image/png;base64,...") HTML বা CSS-এ সরাসরি ফাইল কনটেন্ট এমবেড করে, ছোট অ্যাসেটের জন্য একটি HTTP রাউন্ড-ট্রিপ বাদ দিয়ে। ফেভিকন, ইনলাইন SVG আইকন এবং ছোট UI স্প্রাইট সাধারণ প্রার্থী। ~/.ssh/authorized_keys-এ SSH পাবলিক কী হলো Base64-এনকোড করা DER স্ট্রাকচার। PEM ফরম্যাটে X.509 সার্টিফিকেট হলো হেডার এবং ফুটার লাইনসহ Base64। MIME আবিষ্কার হওয়ার পর থেকে ইমেইল অ্যাটাচমেন্ট Base64-এনকোড করা হয়ে আসছে। JSON বা XML-এ বাইনারি ব্লব সংরক্ষণ করা — REST API-তে সাধারণ যা ফাইল কনটেন্ট বিনিময় করে — Base64 ব্যবহার করে কারণ কোনো ফরম্যাটেই নেটিভ বাইনারি টাইপ নেই।

Base64 সম্পর্কে সবচেয়ে গুরুত্বপূর্ণ ভুল ধারণা হলো এটি কোনো ধরনের নিরাপত্তা প্রদান করে। এটি করে না। Base64 একটি বিপরীতযোগ্য এনকোডিং যার একটি পাবলিক, স্থির অ্যালগরিদম এবং কোনো কী নেই — ডিকোডিং একটি লুকআপ টেবিল অপারেশন যা যেকোনো প্রোগ্রামার দশ লাইনে বাস্তবায়ন করতে পারে। একটি পাসওয়ার্ড বা API কী Base64-এনকোডিং দিয়ে অস্পষ্ট করা ঠিক শূন্য সুরক্ষা প্রদান করে; স্বয়ংক্রিয় স্ক্যানারগুলো নিয়মিতভাবে ক্রেডেনশিয়াল-হার্ভেস্টিং আক্রমণের অংশ হিসেবে সোর্স কোড এবং কনফিগারেশন ফাইলে Base64 স্ট্রিং ডিকোড করে। যদি ডেটা গোপনীয় হতে হয়, ট্রান্সপোর্টের জন্য (ঐচ্ছিকভাবে) সাইফারটেক্সটকে Base64 হিসেবে এনকোড করার আগে এটিকে AES বা একই ধরনের সাইফার দিয়ে এনক্রিপ্ট করুন। এনক্রিপশন নিরাপত্তা প্রদান করে; Base64 শুধু নিরাপদ ASCII ট্রান্সপোর্ট প্রদান করে।

Frequently asked questions

Base64 কী এবং এটি কীসের জন্য ব্যবহৃত হয়?

Base64 হলো একটি এনকোডিং স্কিম যা বাইনারি ডেটা — ফাইল, ইমেজ, বা যেকোনো বাইট — মাত্র ৬৪টি প্রিন্টযোগ্য ASCII ক্যারেক্টার (A–Z, a–z, 0–9, +, /) ব্যবহার করে উপস্থাপন করে। এটি বাইনারিকে টেক্সট-শুধু চ্যানেলের মধ্য দিয়ে নিরাপদে সরাতে ব্যবহৃত হয়: HTML, CSS বা ইমেইলে ইমেজ এমবেড করা, JSON বা XML-এর ভেতরে বাইনারি সংরক্ষণ করা, JWT হেডার ও পেলোড সেগমেন্ট এনকোড করা, এবং কোয়েরি স্ট্রিং-এ মান পাস করা। এটি এমন সিস্টেমের সমস্যা সমাধান করে যা কাঁচা বাইট বাদ দেয়, পরিবর্তন করে বা নষ্ট করে দেয়, সবকিছুকে plain ASCII টেক্সটে রূপান্তরিত করে যা ট্রান্সপোর্টে অপরিবর্তিতভাবে টিকে থাকে।

Base64 কি এনক্রিপশন — এটা কি নিরাপদ?

না। Base64 হলো এনকোডিং, এনক্রিপশন বা হ্যাশিং নয় — এটি কোনো কী ব্যবহার করে না এবং যে কেউ যেকোনো Base64 ডিকোডার দিয়ে এটি তাৎক্ষণিকভাবে ডিকোড করতে পারে, এই টুলটি সহ। এটি শূন্য গোপনীয়তা প্রদান করে এবং কখনও পাসওয়ার্ড, API কী বা প্রাইভেট ডেটা রক্ষা করতে ব্যবহার করা উচিত নয়। Base64 একটি ট্রান্সপোর্ট এনকোডিং, নিরাপত্তা ব্যবস্থা নয়। সংবেদনশীল ডেটা রক্ষা করতে হলে, প্রথমে এটি এনক্রিপ্ট করুন (AES, RSA ইত্যাদি) এবং তারপর নিরাপদ ট্রান্সপোর্টের জন্য ঐচ্ছিকভাবে সাইফারটেক্সটকে Base64-এনকোড করুন — কিন্তু এনক্রিপশনই সুরক্ষা করছে, এনকোডিং নয়।

এই Base64 এনকোডার এবং ডিকোডার কি ফ্রি?

হ্যাঁ, সম্পূর্ণ ফ্রি, কোনো সাইনআপ প্রয়োজন নেই এবং টেক্সটের দৈর্ঘ্য বা ফাইলের আকারে কোনো সীমা নেই। TinyWow ফ্রি ব্যবহারকারীদের প্রতিদিন কয়েকটি রূপান্তরে সীমাবদ্ধ করে, Smallpdf প্রতিদিন ২টি টাস্কে সীমাবদ্ধ রাখে, এবং অনেক সাইটে সম্পূর্ণ ফিচার আনলক করতে অ্যাকাউন্ট প্রয়োজন। UtiloKit-এর Base64 টুলে কোনো দৈনিক সীমা নেই, কোনো অ্যাকাউন্ট প্রয়োজন নেই, এবং কোনো পেওয়াল নেই — আপনার প্রয়োজনীয় প্রতিটি এনকোডিং এবং ডিকোডিং অপারেশনের জন্য এটি ফ্রি। কোনো ইমেইল ঠিকানা নেই, কোনো ক্রেডিট কার্ড নেই, কিছুই না।

এখানে সংবেদনশীল ডেটা এনকোড করা কি নিরাপদ?

হ্যাঁ। সবকিছু আপনার ব্রাউজারে প্রসেস হয় — টেক্সট, ফাইল এবং ইমেজ কখনও একটি সার্ভারে আপলোড হয় না — তাই টোকেন বা ক্রেডেনশিয়ালের মতো সংবেদনশীল কনটেন্টও আপনার ডিভাইসেই থাকে। অনেক জনপ্রিয় Base64 সাইট আপনার ইনপুট তাদের সার্ভারে আপলোড করে; এটি কখনও করে না। আপনি অফলাইনে থেকে এনকোড করে এটি যাচাই করতে পারেন: এটি এখনও কাজ করে।

Base64 কেন এক বা দুটি = চিহ্ন দিয়ে শেষ হয়?

<code>=</code> ক্যারেক্টারগুলো হলো প্যাডিং। Base64 ইনপুটকে ৩-বাইট গ্রুপে এনকোড করে যা প্রতিটি ৪টি ক্যারেক্টার হয়ে যায়; যখন শেষ গ্রুপটি ছোট হয়, <code>=</code> চিহ্ন আউটপুটকে এমন একটি দৈর্ঘ্যে প্যাড করে যা ৪-এর গুণিতক। একটি <code>=</code> মানে শেষ গ্রুপে ২ বাইট ছিল, দুটি <code>=</code> চিহ্ন মানে ১ বাইট ছিল। প্যাডিং কোনো ডেটা বহন করে না, তাই এই টুলটি ডিকোড করার সময় স্বয়ংক্রিয়ভাবে যেকোনো অনুপস্থিত <code>=</code> পুনরুদ্ধার করে।

Base64-এ কোন ক্যারেক্টারগুলো অনুমোদিত?

স্ট্যান্ডার্ড Base64 A–Z, a–z, 0–9 ব্যবহার করে, সাথে + এবং / চিহ্ন, প্যাডিংয়ের জন্য = সহ — মোট ৬৫টি ক্যারেক্টার। অন্য যেকোনো কিছু (স্পেস, লাইন ব্রেক, অন্যান্য যতিচিহ্ন) বর্ণমালার অংশ নয়। URL-সেফ ভ্যারিয়েন্ট + এবং /-কে - এবং _ দিয়ে অদল-বদল করে। এই ডিকোডার এখনও হোয়াইটস্পেস, নিউলাইন এবং URL-সেফ ক্যারেক্টার সহ্য করে এবং এটি গ্রহণ করতে না পারা যেকোনো ক্যারেক্টারের সঠিক অবস্থান বলে দেয়।

Base64-এর অসুবিধাগুলো কী কী?

Base64 ডেটাকে প্রায় ৩৩% বড় করে দেয় কারণ প্রতি ৩ বাইট ৪টি ক্যারেক্টার হয়ে যায় — HTTP রেসপন্স, HTML ফাইল বা CSS বান্ডেলে সেই ওভারহেড দ্রুত জমা হয় যেখানে পেলোড আকার পারফরম্যান্সকে প্রভাবিত করে। এটি মানুষের পড়ার উপযোগী নয়, যা সোর্সে Base64 স্ট্রিং দেখা দিলে কোড রিভিউ এবং ডিবাগিং কঠিন করে তোলে। এটি কোনো ত্রুটি সনাক্তকরণ বা চেকসামিং প্রদান করে না, তাই একটি একক নষ্ট ক্যারেক্টার নীরবে ভুল আউটপুট তৈরি করে। এবং এটি শূন্য গোপনীয়তা প্রদান করে — স্ট্রিংটি যে কেউ দেখলে কয়েক সেকেন্ডে ডিকোড করতে পারে। টেক্সট-শুধু চ্যানেলের মধ্য দিয়ে বাইনারি সরানোর জন্য এটি সঠিক পছন্দ, কিন্তু এটি কমপ্রেশন নয় এবং নিরাপত্তা নয়। বড় পেলোডের জন্য, সঠিক Content-Type হেডারসহ বাইনারি ট্রান্সফার ব্যবহার করুন।

Base64 কি UTF-8-এর মতো একই জিনিস?

না — তারা সম্পূর্ণ ভিন্ন সমস্যা সমাধান করে। UTF-8 হলো একটি ক্যারেক্টার এনকোডিং যা মানুষের পড়ার উপযোগী টেক্সট (অক্ষর, ইমোজি, চিহ্ন) বাইটে রূপান্তরিত করে। Base64 তারপর যেকোনো বাইট — UTF-8 বাইটসহ — নিয়ে সেগুলোকে টেক্সট-শুধু ট্রান্সপোর্টের জন্য নিরাপদ plain ASCII ক্যারেক্টারে রূপান্তরিত করে। দুটি একসাথে স্তরবদ্ধ হয়: একটি ইউনিকোড স্ট্রিং Base64-এনকোড করতে আপনি প্রথমে এটিকে UTF-8 বাইটে রূপান্তরিত করেন, তারপর সেই বাইটগুলোকে Base64 হিসেবে এনকোড করেন। UTF-8 ধাপটি এড়িয়ে যাওয়া হলো সরল Base64 টুলে সবচেয়ে সাধারণ বাগ — তারা JavaScript-এর অভ্যন্তরীণ UTF-16 উপস্থাপনার ওপর কাজ করে, যা মৌলিক ASCII-এর বাইরের যেকোনো কিছুর জন্য এলোমেলো আউটপুট তৈরি করে। এই টুলটি সবসময় প্রথমে ইউনিকোড টেক্সটকে UTF-8-এ রূপান্তরিত করে, তাই ইমোজি এবং প্রতিটি নন-ল্যাটিন স্ক্রিপ্ট সঠিকভাবে এনকোড এবং ডিকোড হয়।

Base64 কি একটি প্রোগ্রামিং বা কোডিং ভাষা?

না। Base64 হলো একটি ডেটা-এনকোডিং স্কিম, কোনো প্রোগ্রামিং বা মার্কআপ ভাষা নয় — চালানো, কম্পাইল করা বা ইন্টারপ্রেট করার কিছু নেই। এটি কেবল একটি বিপরীতযোগ্য অ্যালগরিদম যা যেকোনো বাইনারি ডেটাকে ৬৪টি প্রিন্টযোগ্য ASCII ক্যারেক্টারের একটি স্থির সেটে রূপান্তরিত করে এবং আবার ফিরিয়ে আনে। আপনি যেকোনো ভাষায় (JavaScript, Python, Go, Java ইত্যাদি) লেখা প্রোগ্রামের ভেতরে একটি রূপান্তর ধাপ হিসেবে এটি ব্যবহার করেন কিন্তু Base64 নিজে কোনো ভাষা নয়। এটিকে হেক্সাডেসিমাল নোটেশনের মতো ভাবুন — একটি উপস্থাপনা ফরম্যাট, কোনো ভাষা নয়।

Base64URL কী এবং কখন এটি ব্যবহার করা উচিত?

Base64URL হলো একটি URL- এবং ফাইলনেম-নিরাপদ ভ্যারিয়েন্ট যা <code>+</code> ক্যারেক্টারকে <code>-</code> দিয়ে এবং <code>/</code> ক্যারেক্টারকে <code>_</code> দিয়ে প্রতিস্থাপন করে, এবং <code>=</code> প্যাডিং ক্যারেক্টার সম্পূর্ণভাবে বাদ দেয়। এটি গুরুত্বপূর্ণ কারণ স্ট্যান্ডার্ড + এবং / URL-এ বিশেষ অর্থ বহন করে — ব্রাউজার এবং সার্ভার সেগুলোকে ভুলভাবে ব্যাখ্যা করবে বা percent-encode করবে। JWT হেডার এবং পেলোড সেগমেন্ট, OAuth টোকেন, কোয়েরি-স্ট্রিং প্যারামিটার এবং ফাইলনেমের জন্য Base64URL ব্যবহার করুন যেখানে আপনি একটি নিরাপদ, পঠনযোগ্য স্ট্রিং চান। এই টুলে URL-সেফ মোড টগল করুন এবং এটি স্ট্যান্ডার্ড Base64 এবং URL-সেফ Base64URL উভয়ই স্বয়ংক্রিয়ভাবে এনকোড এবং ডিকোড করে, যেকোনো ভাবে প্যাডিং হ্যান্ডেল করে।

আমি কি ফাইল এবং ইমেজ Base64-এ রূপান্তর করতে পারি?

হ্যাঁ। যেকোনো ফাইল বা ইমেজ ড্রপ বা পেস্ট করে তার Base64 স্ট্রিং বা data URI পান, ইমেজ টাইপের জন্য একটি ইনলাইন প্রিভিউসহ। টুলটি CSS background-image রুল, HTML img src অ্যাট্রিবিউট এবং ফেভিকন link ট্যাগের জন্য রেডি-টু-পেস্ট স্নিপেট তৈরি করে, তাই আপনাকে হাতে data URI স্ট্রিং তৈরি করতে হয় না। Decode মোডে এটি data URI প্রিফিক্স থেকে MIME টাইপ পড়ে বা কাঁচা বাইট (ম্যাজিক বাইট) থেকে ফাইল টাইপ শনাক্ত করে, ইমেজ ইনলাইনে প্রিভিউ করে, এবং সঠিক এক্সটেনশন পুনরুদ্ধারসহ মূল ফাইল ডাউনলোড করার সুযোগ দেয়। PNG, JPG, SVG, WebP, GIF, PDF এবং আরও অনেক কিছুর সাথে কাজ করে।

এটি কি ইউনিকোড এবং ইমোজি সঠিকভাবে হ্যান্ডেল করে?

হ্যাঁ। এনকোডিং UTF-8 ব্যবহার করে ইউনিকোড-সেফ, তাই উচ্চারণচিহ্নযুক্ত ক্যারেক্টার, আরবি, চাইনিজ, জাপানি, কোরিয়ান এবং ইমোজি সবই কোনো নষ্ট হওয়া ছাড়াই সঠিকভাবে রাউন্ড-ট্রিপ করে। এটি সরল Base64 টুলে সবচেয়ে সাধারণ ব্যর্থতা: তারা প্রথমে সঠিক UTF-8 বাইটে রূপান্তরিত না করে JavaScript-এর অভ্যন্তরীণ UTF-16 স্ট্রিং উপস্থাপনার ওপর কাজ করে, মৌলিক ASCII-এর বাইরের যেকোনো কিছুর জন্য এলোমেলো আউটপুট তৈরি করে। এই টুলটি প্রথমে UTF-8-এ রূপান্তরিত করে, তাই প্রতিটি ক্যারেক্টার স্ক্রিপ্ট বা ভাষা নির্বিশেষে সঠিকভাবে এনকোড এবং ডিকোড হয়।

আমার ডিকোড করা টেক্সট এলোমেলো দেখাচ্ছে — আমি কি এটি ঠিক করতে পারি?

হ্যাঁ। Base64 কোনো ক্যারেক্টার-সেট তথ্য বহন করে না, তাই মূলত একটি নন-UTF-8 ক্যারেক্টার-সেটে এনকোড করা টেক্সট UTF-8 হিসেবে ডিকোড করা হলে এলোমেলো দেখাতে পারে। একই বাইটগুলোকে UTF-16 (বিগ-এন্ডিয়ান এবং লিটল-এন্ডিয়ান উভয়ই), Latin-1 (ISO-8859-1), Windows-1252, ASCII, Shift_JIS (জাপানি), বা GBK (সরলীকৃত চাইনিজ) হিসেবে পুনর্ব্যাখ্যা করতে 'Decode as' নির্বাচক ব্যবহার করুন যতক্ষণ না টেক্সটটি সঠিকভাবে পড়া যায়। এটি সবচেয়ে বেশি গুরুত্বপূর্ণ সেই Base64 স্ট্রিংগুলোর জন্য যেগুলো পুরনো সিস্টেম, ইমেইল ক্লায়েন্ট বা পূর্ব এশীয় সফটওয়্যার থেকে এসেছে যা UTF-8-এর পরিবর্তে একটি আঞ্চলিক এনকোডিং ডিফল্ট করে।

আমার Base64 কেন ডিকোড হচ্ছে না — এটি অবৈধ বলছে কেন?

সবচেয়ে সাধারণ কারণগুলো দিয়ে শুরু করুন: অতিরিক্ত হোয়াইটস্পেস বা নিউলাইন (এই ডিকোডার স্বয়ংক্রিয়ভাবে এগুলো সরিয়ে দেয়), + এবং /-এর পরিবর্তে - এবং _-এর মতো URL-সেফ ক্যারেক্টার (এটিও স্বয়ংক্রিয়ভাবে হ্যান্ডেল হয়), এবং শেষে অনুপস্থিত = প্যাডিং (স্বয়ংক্রিয়ভাবে পুনরুদ্ধার হয়)। যদি স্ট্রিংটি তারপরও ব্যর্থ হয়, সম্ভবত Base64 বর্ণমালার বাইরে একটি ক্যারেক্টার আছে — একটি স্পেস, একটি percent সাইন, একটি ইউনিকোড ক্যারেক্টার, বা একটি ছড়িয়ে থাকা HTML entity। ডিকোডার আপনাকে ঠিক কোন ক্যারেক্টারটি অবৈধ এবং স্ট্রিংয়ে তার অবস্থান বলে দেয় যাতে আপনি এটি খুঁজে ঠিক করতে পারেন। উৎস থেকে আবার raw স্ট্রিংটি কপি করুন, কারণ কপি-পেস্ট কখনও কখনও অদৃশ্য ইউনিকোড ক্যারেক্টার বা স্মার্ট কোট প্রবর্তন করে যা সঠিক দেখায় কিন্তু Base64 নয়।

TinyWow বা it-tools-এর মতো অন্যান্য Base64 টুলের সাথে এটি কীভাবে তুলনীয়?

TinyWow এবং Smallpdf মূলত PDF/ইমেজ টুল যা তাদের সার্ভারে ফাইল আপলোড করে। it-tools.tech-এর Base64 টুল ভালো কিন্তু একটি সেলফ-হোস্টেড অ্যাপ। এখানকার মূল পার্থক্য হলো এনকোডিং এবং ডিকোডিং সম্পূর্ণভাবে আপনার ব্রাউজারে ঘটে — আপনার ডেটা কখনও কোথাও ট্রান্সমিট হয় না। এছাড়াও, এই টুলটি ক্যারেক্টার-সেট নির্বাচন, MIME লাইন-র‍্যাপিং, ফাইল প্রিভিউ এবং URL-সেফ Base64 একসাথে হ্যান্ডেল করে, কোনো অ্যাকাউন্ট প্রয়োজন ছাড়াই।

তাৎক্ষণিক ত্রুটি ইঙ্গিত সহ JSON সুন্দর করুন, মিনিফাই ও যাচাই করুন।

ডেভেলপার