ইমেজ থেকে Base64

Base64 ইমেজ (ডেটা URI) কী?

একটি ডেটা URI কোনো আলাদা ফাইলের দিকে ইঙ্গিত করার বদলে ইমেজকে সরাসরি টেক্সটের ভেতরে এম্বেড করে। এর রূপ হলো data:<mime>;base64,<encoded-bytes> — উদাহরণস্বরূপ data:image/png;base64,iVBORw0KGgo…। যেহেতু এটি সাধারণ টেক্সট, আপনি এটিকে সরাসরি HTML, CSS, JSON, SVG বা Markdown-এ দিতে পারেন, এবং ব্রাউজার কোনো দ্বিতীয় নেটওয়ার্ক অনুরোধ ছাড়াই ইমেজটি রেন্ডার করে। এনকোড করা কখনো ছবিটি পরিবর্তন করে না — এটি ঠিক সেই ফাইলের বাইট-বাই-বাইট টেক্সট রূপ যা আপনি দিয়েছেন।

সাইজ ও ক্যাশিং — এই বিনিময়

Base64 প্রতি 3 বাইটকে 4টি ASCII অক্ষরে বদলে দেয়, তাই এনকোড করা টেক্সট সবসময় বাইনারি ফাইলের চেয়ে প্রায় 33% বড় হয়, সঙ্গে একটি ছোট হেডার। এটি কয়েকটি খুব ছোট অ্যাসেটের জন্য ঠিক আছে কিন্তু বড়টির জন্য অপচয়। বড় ফাঁদটি হলো ক্যাশিং: একটি লিঙ্ক করা ইমেজ ফাইল একবার ডাউনলোড হয়ে ক্যাশ হয়ে যায়, তারপর সর্বত্র পুনরায় ব্যবহৃত হয়, যেখানে একটি ইনলাইন ডেটা URI প্রতিটি পেজ বা স্টাইলশিটের অংশ হিসেবে আবার ডাউনলোড হয় যেটিতে এটি থাকে, এবং নিজে থেকে ক্যাশ হতে পারে না। ছোট ইনলাইন করুন, বড় লিঙ্ক করুন।

কখন ইনলাইন বনাম কখন লিঙ্ক

পরামর্শ

• আগে কম্প্রেস বা রিসাইজ করুন। ছোট ইমেজের Base64 একটি ছোট স্ট্রিং হয় — এনকোড করার আগে কোনো ফটোকে ইমেজ কম্প্রেসর বা ইমেজ রিসাইজার দিয়ে চালান।
• SVG বিশেষভাবে ভালো ইনলাইন হয় — ভেক্টর আইকন তীক্ষ্ণ থাকে এবং Base64 হিসেবে র‍্যাস্টারের চেয়ে ভালো কম্প্রেস হয়; CSS ব্যাকগ্রাউন্ড ও কম্পোনেন্ট লাইব্রেরির জন্য দারুণ।
• HTML/CSS সাইজের উপর নজর রাখুন। কয়েকটি ইনলাইন আইকন ঠিক আছে; ডজন খানেক বড় ডেটা URI আপনার মার্কআপকে ভারী ও পার্স হতে ধীর করে দেয়।
• টেক্সট চাই, ইমেজ নয়? সাধারণ টেক্সট ও স্ট্রিংয়ের জন্য Base64 এনকোডার / ডিকোডার ব্যবহার করুন।

Base64 আসলে কীভাবে কাজ করে

Base64 হলো বাইনারি ডেটাকে কেবল নিরাপদ টেক্সট অক্ষরের একটি ছোট সেট দিয়ে লেখার একটি উপায়। এর বর্ণমালা ঠিক 64টি প্রতীক — বড় হাতের অক্ষর A–Z, ছোট হাতের a–z, অঙ্ক 0–9, সঙ্গে + ও / — এবং মানকটি RFC 4648-এ সংজ্ঞায়িত। এনকোডিং একটি নির্দিষ্ট ছন্দে কাজ করে: এটি ডেটাকে একবারে তিন বাইট (24 বিট) নেয় এবং সেগুলোকে 6 বিটের চারটি অক্ষর হিসেবে আবার লেখে (যেহেতু 2⁶ = 64, প্রতিটি অক্ষর পরিষ্কারভাবে একটি বর্ণমালা প্রতীকে ম্যাপ হয়)। যখন ডেটা তিনে সমানভাবে ভাগ হয় না, তখন এক বা দুটি = অক্ষর শেষে প্যাডিং করে।

সেই 3-বাইট-থেকে-4-অক্ষর অনুপাতই ঠিক সেখানে যেখান থেকে ~33% সাইজ বৃদ্ধি আসে: প্রতি তিন ইনপুট বাইটের জন্য চারটি আউটপুট অক্ষর মানে একটি 4/3 বিস্তার। একটি সাধারণ ভাইও আছে, base64url, যা + ও /-কে - ও _ দিয়ে বদলে দেয় যাতে ফলাফলটি কোনো অতিরিক্ত এস্কেপিং ছাড়াই কোনো URL বা ফাইলনামে দেওয়া নিরাপদ থাকে — এই ভ্যারিয়েন্টটিই JSON Web Tokens (JWTs)-এর ভেতরে ব্যবহৃত হয়।

ডেটা URI স্কিম

সেই Base64-কে একটি ব্যবহারযোগ্য ঠিকানায় মোড়ানো ডেটা URI স্কিম-এর কাজ, যা RFC 2397-এ 1998 সালে Larry Masinter সংজ্ঞায়িত করেছিলেন। এর ব্যাকরণ হলো data:[<mediatype>][;base64],<data>। কিছু বিষয় জানা দরকার: কমা সবসময় প্রয়োজন, খালি ডেটার জন্যও; ;base64 টোকেনটিই সংকেত দেয় যে পেলোড Base64, percent-encoded টেক্সট নয়; এবং আপনি যদি মিডিয়া টাইপ পুরোপুরি বাদ দেন, তবে ডিফল্ট text/plain;charset=US-ASCII। কোনো ইমেজের জন্য আপনি সবসময় একটি স্পষ্ট টাইপ যেমন data:image/png;base64,… দেখবেন যাতে ব্রাউজার জানে যে একে কীভাবে ডিকোড করতে হবে। এই কারণেই এই টুল MIME টাইপ জানায় — এটি আপনার ফাইল থেকেই সরাসরি পড়া হয়, তাই URI সেই ঠিক ফরম্যাটের জন্য সঠিক।

Base64 আদৌ কেন আছে

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

এই ইতিহাস Base64 সম্পর্কে বোঝার মতো সবচেয়ে গুরুত্বপূর্ণ বিষয়টির দিকে ইঙ্গিত করে: এটি একটি এনকোডিং, কম্প্রেশনও নয় এনক্রিপশনও নয়। এটি ডেটাকে ছোট করে না — এটি একে প্রায় এক-তৃতীয়াংশ বড় করে — এবং এটি কোনো কিছু সুরক্ষিত করে না, কারণ যে কেউ একে সঙ্গে সঙ্গে ডিকোড করতে পারে (এই টুলই করবে)। আপনি যদি Base64 দেখে ধরে নেন যে এটি "এনক্রিপ্টেড", তবে আপনি ভুল; এটি কেবল পাঠযোগ্য টেক্সটের পোশাকে বাইনারি।

ইনলাইন করা কি এখনো পারফরম্যান্সে সাহায্য করে?

ডেটা URI-র পক্ষে ক্লাসিক যুক্তি ছিল HTTP অনুরোধ দূর করা, এবং HTTP/1.1-এর অধীনে — যেখানে ব্রাউজার প্রতি হোস্টে কেবল কয়েকটি কানেকশন খুলতে পারত — একটি রাউন্ড ট্রিপ বাঁচানো একটি আসল জয় ছিল। HTTP/2 অঙ্কটি বদলে দিয়েছে: এটি বহু ফাইলকে একটি কানেকশনে মাল্টিপ্লেক্স করে, তাই অতিরিক্ত অনুরোধের খরচ দ্রুত কমে গেছে এবং ইনলাইন করার যুক্তি দুর্বল হয়ে পড়েছে। আরও একটি সূক্ষ্ম করও আছে: Base64 টেক্সট সমতুল্য কাঁচা বাইনারির চেয়ে gzip বা Brotli দিয়ে কম দক্ষভাবে কম্প্রেস হয়, তাই অনুরোধে আপনি যে কিছু বাইট "বাঁচিয়েছেন" তার কিছু তারে ফিরে আসে। টেকসই নিয়মটি কেবল এটুকু — ছোট ইনলাইন করুন, বড় লিঙ্ক করুন — একটি ক্ষুদ্র সংকটজনক আইকন কোনো render-blocking অনুরোধ এড়াতে এখনো ইনলাইন করার মতো হতে পারে, কিন্তু কোনো বড় জিনিস একটি সাধারণ, আলাদাভাবে ক্যাশ-যোগ্য ফাইলই থাকা উচিত। (একটি সুন্দর ব্যতিক্রম: কোনো SVG-র জন্য, মার্কআপকে URL-encode করা সাধারণত Base64-encode করার চেয়ে ছোট হয়, কারণ SVG আগে থেকেই টেক্সট এবং Base64 আবরণ থেকে এর কোনো লাভ হয় না।)

নিরাপত্তা ও Content Security Policy নিয়ে একটি নোট

যেহেতু কোনো ডেটা URI যেকোনো সামগ্রী বহন করতে পারে, এর নিরাপত্তা তাৎপর্য মনোযোগের যোগ্য। কোনো Content Security Policy-র অধীনে, img-src-এ data: অনুমতি দেওয়া সাধারণ ও যথেষ্ট কম-ঝুঁকির (ইনলাইন আইকন এভাবেই কাজ করে), কিন্তু script-src-এ data: অনুমতি দেওয়া বিপজ্জনক — একজন আক্রমণকারী কোনো data: স্ক্রিপ্ট URL-এর মাধ্যমে কোড লুকিয়ে চালাতে পারে, তাই নিরাপত্তা গাইড সেখানে কখনো এটি অনুমতি না দেওয়ার পরামর্শ দেয়। ডেটা URI-র অপব্যবহার ফিশিং পেজ তৈরিতেও হয়েছে, এই কারণে আধুনিক ব্রাউজার এখন কোনো data: URL-এ সরাসরি শীর্ষ-স্তরের নেভিগেশন ব্লক করে দেয়। এর কোনোটিই আপনার নিজের পেজের জন্য কোনো ইমেজ এনকোড করায় প্রভাব ফেলে না; এর কেবল অর্থ হলো আপনার কোনো ডেটা URI-কে তার সক্রিয় সামগ্রী হিসেবে গণ্য করা উচিত, নিষ্ক্রিয় টেক্সট হিসেবে নয়।

এর পেছনের ব্রাউজার APIs

এই কনভার্টার ব্রাউজারের নিজস্ব FileReader.readAsDataURL()-এর উপর তৈরি, যা আপনার ফাইলকে স্থানীয়ভাবে পড়ে এবং সম্পূর্ণ data:<mime>;base64,… স্ট্রিং ফিরিয়ে দেয় — "কাঁচা Base64" আউটপুট কেবল সেই স্ট্রিং যার প্রিফিক্স সরিয়ে ফেলা হয়েছে। আপনি btoa() ও atob(), সেই নিম্ন-স্তরের এনকোড ও ডিকোড ফাংশনও হয়তো দেখেছেন। এগুলোর একটি বিখ্যাত ফাঁদ আছে: btoa() প্রতিটি অক্ষরকে একটিমাত্র বাইট হিসেবে গণ্য করে, তাই এটি U+00FF-এর উপরের যেকোনো অক্ষরে এরর দেয় — এটিকে কোনো ইমোজি বা অ-ল্যাটিন অক্ষর দিলে এটি ব্যর্থ হয়। আধুনিক সমাধান হলো আগে TextEncoder দিয়ে টেক্সটকে বাইটে বদলানো (বা নতুন Uint8Array Base64 হেল্পার ব্যবহার করা)। ইমেজের জন্য এটি কখনো সামনে আসে না, কারণ readAsDataURL কাঁচা বাইটের উপর কাজ করে — এবং এই কারণেই এটি এখানে সঠিক টুল।

কোনো ডেটা URI আসলে কোথায় যায়

একবার আপনার কাছে এনকোড করা স্ট্রিং এসে গেলে, প্রশ্ন হলো এটি কোথায় পেস্ট করবেন। একই ডেটা URI বহু প্রসঙ্গে কাজ করে, এই কারণেই এই টুল সাধারণ প্রসঙ্গের জন্য প্রস্তুত স্নিপেট তৈরি করে দেয়:

এদের প্রতিটিই ছবিটিকে সরাসরি ডকুমেন্টে এম্বেড করে, তাই কোনো আলাদা ইমেজ ফাইলের জন্য দ্বিতীয় অনুরোধ হয় না। এটাই পুরো আকর্ষণ — এবং, উপরে যেমন বলা হয়েছে, এটাই পুরো বিনিময়ও, কারণ প্রতিবার লোড হওয়ার সময় বাইটগুলো হোস্ট ফাইলের ভেতরে সঙ্গে চলে।

ইমেলে ডেটা URI কেন নির্ভরযোগ্য

একটি প্রসঙ্গ বিশেষ উল্লেখের যোগ্য: ইমেল। অনেক ইমেল ক্লায়েন্ট ডিফল্টভাবে রিমোট ইমেজ ব্লক করে দেয় — যতক্ষণ না পাঠক "ইমেজ দেখান"-এ ক্লিক করে, তারা কোনো বাহ্যিক সার্ভারে হোস্ট করা ছবি লোড করে না, কিছুটা ট্র্যাকিং পিক্সেলের বিরুদ্ধে গোপনীয়তা ব্যবস্থা হিসেবে। কোনো ডেটা URI হিসেবে এম্বেড করা ইমেজ এটিকে পুরোপুরি এড়িয়ে যায়, কারণ কোথাও থেকে কিছু ফেচ করতে হয় না; ছবিটি ইতিমধ্যেই বার্তার ভেতরে। এটি ডেটা URI-কে কোনো HTML ইমেল স্বাক্ষরে একটি ছোট লোগো বসানোর নির্ভরযোগ্য উপায় করে তোলে, যেখানে আপনি চান এটি প্রতিবার, প্রতিটি ক্লায়েন্টে, কোনো ভাঙা-ইমেজ প্লেসহোল্ডার ছাড়াই দেখাক। সেই একই সতর্কতা এখনো প্রযোজ্য — একে ছোট রাখুন, কারণ এনকোড করা বাইট ইমেলের প্রতিটি কপির ভেতরে ভ্রমণ করে।

ক্যাশিং খরচ, বিস্তারিতভাবে

সবচেয়ে বড় অসুবিধা সম্পর্কে সুনির্দিষ্ট হওয়া দরকার, কারণ এটাই সেটি যা লোকে উপেক্ষা করে। একটি সাধারণ লিঙ্ক করা ইমেজ একবার ডাউনলোড হয় এবং তারপর প্রতিটি পরবর্তী পেজে ব্রাউজার ক্যাশ থেকে পরিবেশিত হয় — দ্রুত, এবং অতিরিক্ত বাইট মুক্ত। একটি ইনলাইন ডেটা URI নিজে থেকে ক্যাশ হতে পারে না; এটি HTML বা CSS ফাইলের ভেতরে থাকে, তাই প্রতিবার ফাইল বদলালে সেই ফাইলের অংশ হিসেবে আবার ডাউনলোড হয়, এবং পেজগুলোর মধ্যে ভাগ করা যায় না। একই আইকন কুড়িটি পেজে ইনলাইন করুন এবং ব্রাউজার কার্যকরভাবে একটি কপি ক্যাশ করার বদলে একে কুড়িবার ডাউনলোড করে। এটাই "ছোট ইনলাইন করুন, বড় লিঙ্ক করুন" নিয়মের পেছনের নির্ণায়ক কারণ: একটি ক্ষুদ্র একক অ্যাসেট এম্বেড করা ঠিক আছে, কিন্তু পেজগুলোতে পুনরায় ব্যবহৃত যেকোনো কিছু প্রায় সবসময় একটি আলাদা, ক্যাশ-যোগ্য ফাইলেই থাকা উচিত।

কোনো ডেটা URI-র গঠন, ফিল্ড-বাই-ফিল্ড

কোনো ডেটা URI দেখতে এলোমেলো অক্ষরের দেয়ালের মতো, কিন্তু এর একটি পরিষ্কার, পাঠযোগ্য গঠন আছে। data:image/png;base64,iVBORw0KGgo… নিন এবং একে এর অংশে ভাঙুন:

পেলোডে একটি মজার ইঙ্গিতও লুকিয়ে আছে: iVBORw0KGgo দিয়ে শুরু হওয়া কোনো Base64 স্ট্রিং প্রায় সবসময় একটি PNG হয় (সেই অক্ষরগুলো PNG ফাইল স্বাক্ষর এনকোড করে), যেখানে /9j/ দিয়ে শুরু হওয়া একটি JPEG হয়। একবার আপনি অংশগুলো পড়তে পারলে, কোনো ডেটা URI আর রহস্যময় থাকে না — এটি কেবল একটি মিডিয়া টাইপ, base64 শব্দটি, এবং এনকোড করা ফাইল, একটি কমা দিয়ে জোড়া। এটাই ঠিক সেই স্ট্রিং যা এই টুলের "ডেটা URI" বক্স আপনাকে দেয়, এবং "কাঁচা Base64" বক্স সেই একই জিনিস যেখানে কমা পর্যন্ত এবং তা সহ সবকিছু সরিয়ে ফেলা হয়েছে।

কোনো ডেটা URI-কে আবার ফাইলে বদলানো

যেহেতু Base64 একটি বিপরীতমুখী এনকোডিং, প্রক্রিয়াটি উভয় দিকেই চলে — এবং এটাই উপরের "Base64 → ইমেজ" ট্যাব করে। কোনো পূর্ণ data: URI, বা ফরম্যাট বেছে কেবল কাঁচা Base64 পেস্ট করুন, এবং টুলটি টেক্সটকে আবার মূল বাইটে ডিকোড করে, ছবির প্রিভিউ দেখায়, এবং একে একটি আসল ফাইল হিসেবে ডাউনলোড করতে দেয়। ডিকোড কেবল প্রতিটি ধাপ উল্টে দেয়: এটি ফাইল ফরম্যাট জানতে মিডিয়া টাইপ পড়ে, data:…;base64, প্রিফিক্স সরায়, এবং প্রতি চারটি Base64 অক্ষরকে আবার তিন বাইটে বদলায়। যদি স্ট্রিংটি বৈধ ইমেজ ডেটা না হয় — সাধারণত একটি অসম্পূর্ণ copy-paste-এর কারণে — তবে ভাঙা ইমেজের বদলে আপনি একটি পরিষ্কার এরর পাবেন, কারণ বাইটগুলো এমন কোনো ছবিতে ডিকোড হবে না যা ব্রাউজার রেন্ডার করতে পারে। এটি এনকোডিংয়ের ঠিক বিপরীত, এবং কোনো স্টাইলশিট বা HTML ফাইলে কারও দ্বারা ডেটা URI হিসেবে এম্বেড করা ইমেজ পুনরুদ্ধারের একটি সহজ উপায়।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

আমার ইমেজ কি কোনো সার্ভারে আপলোড হয়?

না। ইমেজটি অন্তর্নির্মিত FileReader API দিয়ে সম্পূর্ণ আপনার ব্রাউজারে পড়া হয় এবং স্থানীয়ভাবে Base64-তে রূপান্তরিত হয় — এটি কখনো আপনার ডিভাইস থেকে বাইরে যায় না এবং কখনো লগ বা ট্রান্সমিট হয় না। পেজ লোড হয়ে যাওয়ার পরে এটি অফলাইনেও কাজ করে, তাই ব্যক্তিগত স্ক্রিনশট, আইডি ফটো বা অভ্যন্তরীণ অ্যাসেটের জন্য এটি নিরাপদ।

ডেটা URI কী এবং ফলাফল আমি কোথায় পেস্ট করব?

একটি ডেটা URI দেখতে এমন data:image/png;base64,iVBORw0KGgo… — MIME টাইপ, base64 শব্দটি, তারপর এনকোড করা বাইট। আপনি পুরো স্ট্রিংটি সরাসরি কোনো HTML <img src="…">, কোনো CSS background-image: url("…"), বা কোনো Markdown ইমেজে দিতে পারেন। এই টুল আপনার জন্য সেই তিনটি স্নিপেট তৈরি করে দেয় যাতে আপনি ঠিক যেটি দরকার সেটিই কপি করতে পারেন।

Base64 মূল ফাইলের চেয়ে বড় কেন হয়?

Base64 প্রতি 3 বাইটকে 4টি ASCII অক্ষর হিসেবে এনকোড করে, তাই টেক্সট সবসময় বাইনারি ইমেজের চেয়ে প্রায় 33% বড় হয় — সঙ্গে ছোট data:…;base64, হেডার। কোনো ইমেজকে সরাসরি টেক্সটে এম্বেড করার এটাই বিনিময়। এটি ছোট অ্যাসেটের জন্য ঠিক আছে কিন্তু বড় ফটোর জন্য অপচয়, যেগুলোকে সাধারণ ফাইল হিসেবে লিঙ্ক করা ভালো।

আমি কোন কোন ইমেজ ফরম্যাট এনকোড করতে পারি?

যেকোনো ফরম্যাট যা আপনার ব্রাউজার ফাইল হিসেবে পড়তে পারে — PNG, JPEG, GIF, WebP, SVG, BMP ও ICO সবই কাজ করে। MIME টাইপ ফাইল থেকেই নেওয়া হয়, তাই তৈরি ডেটা URI সেই ফরম্যাটের জন্য সঠিক। এনকোড করা ইমেজকে পরিবর্তন বা পুনরায় কম্প্রেস করে না; এটি মূল ফাইলের বাইট-বাই-বাইট টেক্সট রূপ।

আমি কি কোনো Base64 স্ট্রিংকে আবার ইমেজে ডিকোড করতে পারি?

হ্যাঁ — “Base64 → ইমেজ” ট্যাবে যান এবং হয় একটি পূর্ণ ডেটা URI অথবা কেবল কাঁচা (raw) Base64 পেস্ট করুন (তারপর এর ফরম্যাট বেছে নিন)। টুলটি ইমেজের প্রিভিউ দেখায় এবং এটিকে একটি আসল ফাইল হিসেবে ডাউনলোড করতে দেয়। যদি স্ট্রিংটি বৈধ ইমেজ ডেটা না হয় তবে একটি ভাঙা ইমেজের বদলে আপনি একটি পরিষ্কার এরর পাবেন।

কোনো ইমেজকে Base64 হিসেবে ইনলাইন করলে কি পেজ স্পিড ভালো হয়?

কয়েকটি খুব ছোট অ্যাসেটের জন্য, হ্যাঁ — এটি অতিরিক্ত HTTP অনুরোধ সরিয়ে দেয়। কিন্তু ইনলাইন ইমেজ আলাদাভাবে ক্যাশ হতে পারে না এবং HTML/CSS-কে ভারী করে তোলে, তাই ছোট আইকনের বাইরে যেকোনো কিছুর জন্য এটি সাধারণত ক্ষতিকর। একটি ভালো নিয়ম হলো — কয়েক কিলোবাইটের কম অ্যাসেট ইনলাইন করুন এবং তার চেয়ে বড় সবকিছু লিঙ্ক করুন।

সম্পর্কিত টুল

• Base64 এনকোডার / ডিকোডার (টেক্সট)
• ইমেজ কম্প্রেসর
• ইমেজ রিসাইজার
• ইমেজ থেকে PDF

সব ব্রাউজার টুল দেখুন →