تصویر سے Base64

تصویر کو آن لائن Base64 میں بدلیں

یہ مفت تصویر سے Base64 کنورٹر کسی بھی تصویر کو براہِ راست آپ کے براؤزر میں ایک Base64 string یا data URI میں بدل دیتا ہے — نہ کوئی اپلوڈ، نہ سائن اپ، اور نہ ہی کوئی سافٹ ویئر انسٹال کرنے کی ضرورت۔ فائل کو ڈراپ کریں، براؤز کرنے کے لیے کلک کریں، کلپ بورڈ سے پیسٹ کریں، یا کسی URL سے تصویر لوڈ کریں، اور فوراً ایک کاپی کے لیے تیار data:image/…;base64,… string کے ساتھ ساتھ متعلقہ CSS، HTML اور Markdown سنیپٹس حاصل کریں۔

یہ دونوں سمتوں میں کام کرتا ہے: کسی تصویر کو Base64 میں اینکوڈ کریں، یا ٹیب بدل کر کسی Base64 string کو واپس ایک قابلِ مشاہدہ اور ڈاؤن لوڈ کے قابل تصویر میں ڈی کوڈ کریں۔ چونکہ پورا ٹول براؤزر کے FileReader اور Canvas APIs کا استعمال کرتے ہوئے client-side چلتا ہے، اس لیے آپ کی تصاویر کبھی بھی آپ کے آلے سے باہر نہیں جاتیں — یہ اسے پرائیویٹ لوگو، اسکرین شاٹس اور غیر شائع شدہ آرٹ ورک کے لیے محفوظ بناتا ہے۔ یہ base64.guru اور base64encoder.io جیسے مقبول متبادلات کے برعکس ہے، جو پروسیسنگ کے لیے آپ کی تصاویر کو دور دراز سرورز پر اپلوڈ کرتے ہیں۔

تصویر کو Base64 میں کیسے بدلیں

1. اپنی تصویر کو اپلوڈ باکس پر ڈریگ اینڈ ڈراپ کریں، فائل منتخب کرنے کے لیے کلک کریں، تصویر پیسٹ کریں، یا ایک تصویر کا URL درج کریں۔ 2. ٹول فائل کو مقامی طور پر پڑھتا ہے اور فوراً Base64 data URI تیار کر دیتا ہے، جس میں اصل سائز، اینکوڈ شدہ سائز اور تصویر کے ابعاد ظاہر ہوتے ہیں۔ 3. آؤٹ پٹ کو اپنی ضرورت کے مطابق فارمیٹ میں کاپی کریں — خام Base64، مکمل data URI، ایک CSS background-image رول، ایک HTML <img> ٹیگ، یا Markdown — یا اسے .txt فائل کے طور پر ڈاؤن لوڈ کریں۔

دوسری سمت جانے کے لیے، Base64 → Image ٹیب کھولیں، ایک data URI یا خام Base64 string پیسٹ کریں، اور ٹول اسے ڈی کوڈ کرتا ہے، تصویر کا پیش منظر دکھاتا ہے، اور درست فائل ایکسٹینشن کے ساتھ ایک کلک ڈاؤن لوڈ پیش کرتا ہے۔ پورا راؤنڈ ٹرپ — اینکوڈ پھر ڈی کوڈ — اس بات کی تصدیق کرتا ہے کہ آپ کا Base64 آؤٹ پٹ درست اور مکمل ہے۔

HTML، CSS، Markdown اور ای میل میں Base64 تصاویر کو ایمبیڈ کریں

ایک Base64 data URI آپ کو کسی تصویر کو الگ فائل سے لنک کرنے کے بجائے براہِ راست آپ کے کوڈ کے اندر بطور متن ایمبیڈ کرنے دیتا ہے۔ HTML میں، string کو کسی image ٹیگ کے src میں ڈالیں؛ CSS میں، اسے پس منظر کے لیے url("…") کے اندر رکھیں؛ Markdown میں، image سنٹیکس ![alt](data:image/png;base64,…) استعمال کریں۔ یہ ایک اضافی HTTP درخواست کو ختم کر دیتا ہے، جو چھوٹے آئیکنز، سنگل فائل صفحات اور آف لائن ڈیموز کے لیے مفید ہے۔

inlining خاص طور پر HTML ای میل میں عام ہے، جہاں تصاویر کو پیغام میں بنڈل کرنا ٹوٹے ہوئے لنکس اور «تصاویر ڈاؤن لوڈ کریں» کے پیغامات سے بچاتا ہے — اگرچہ کچھ کلائنٹس جیسے Outlook Base64 تصاویر کو بلاک کر سکتے ہیں، اس لیے ہمیشہ پہلے ٹیسٹ کریں۔ ڈویلپرز چھوٹی Base64 تصاویر کو JSON پے لوڈز، ڈیٹابیسز اور کنفیگریشن فائلوں میں بھی محفوظ کرتے ہیں جہاں ایک binary فائل بے ڈھنگی ہوتی۔

JavaScript اور Python میں تصویر سے Base64

JavaScript میں، براؤزر آپ کے لیے کام کرتا ہے: const r = new FileReader(); r.onload = () => use(r.result); r.readAsDataURL(file); آپ کو مکمل data URI دیتا ہے۔ React میں، اسے ایک file input پر onChange ہینڈلر میں لپیٹیں؛ Next.js میں، آپ Node کے Buffer.from(bytes).toString('base64') کا استعمال کرتے ہوئے تصاویر کو server-side بھی اینکوڈ کر سکتے ہیں۔ یہ کنورٹر بالکل FileReader API استعمال کرتا ہے، اس لیے جو کچھ آپ کاپی کرتے ہیں وہ اس سے مماثل ہے جو آپ کو اپنے کوڈ میں ملے گا۔

Python میں، خام bytes کو base64 ماڈیول کے ساتھ اینکوڈ کریں: base64.b64encode(open('image.png','rb').read()).decode()، پھر اسے data:image/png;base64, کے ساتھ prefix کریں۔ Pillow (PIL) کے ساتھ، تصویر کو پہلے ایک BytesIO بفر میں محفوظ کریں اور بفر کو Base64 اینکوڈ کریں۔ کوئی اسکرپٹ چلائے بغیر اپنے آؤٹ پٹ کی جلدی تصدیق کے لیے اس ٹول کا استعمال کریں۔

حریفوں کا موازنہ: UtiloKit بمقابلہ base64.guru، base64encoder.io، browserling

base64.guru آن لائن سب سے زیادہ دیکھے جانے والے Base64 ٹولز میں سے ایک ہے، لیکن یہ آپ کی تصاویر کو اپنے سرور پر اپلوڈ کرتا ہے — جو لوگو، پروڈکٹ ماک اپس یا خفیہ دستاویزات کے لیے ایک اہم رازداری کا مسئلہ ہے۔ base64encoder.io اسی طرح کام کرتا ہے، فائلوں کو server-side پروسیس کرتا ہے۔ Browserling کا image-to-Base64 ٹول بھی server-side ہے اور مفت صارفین کو فائل سائز (مفت درجے پر 75 MB کی حد) اور روزانہ تبدیلیوں کی تعداد سے محدود کرتا ہے۔

UtiloKit مکمل طور پر آپ کے براؤزر میں چلتا ہے جس میں آپ کے آلے کی RAM جتنی گنجائش ہے اس کے علاوہ فائل سائز کی کوئی پابندی نہیں، کوئی روزانہ حد نہیں، اور کوئی ڈیٹا آپ کی مشین سے باہر نہیں جاتا۔ آپ کو وہی آؤٹ پٹ ملتا ہے — ایک درست data URI — ان اضافی سنیپٹس (CSS، HTML، Markdown) کے ساتھ جو مذکورہ بالا ٹولز فراہم نہیں کرتے۔ خصوصی اثاثوں کے ساتھ کام کرنے والی ٹیموں کے لیے، رازداری کا فرق اہم ہے: کوئی سرور کبھی آپ کی تصویر نہیں دیکھتا۔

Base64 کب استعمال کریں — اور کب نہیں

Base64 چھوٹے، شاذ و نادر ہی بدلنے والے اثاثوں کے لیے بہترین ہے، لیکن یہ مفت نہیں ہے: اینکوڈ شدہ متن اصل فائل سے تقریباً 33% بڑا ہوتا ہے، اور ایک inline تصویر کو الگ سے cache یا lazy-load نہیں کیا جا سکتا۔ بڑی تصاویر یا کئی صفحات پر دوبارہ استعمال ہونے والی تصاویر کے لیے، ایک عام image فائل (اور HTTP caching) تیزی سے لوڈ ہوگی۔ ایک اصول کے طور پر، ~10 KB سے کم چھوٹے آئیکنز اور لوگوز کو inline کریں، اور اس سے بڑی ہر چیز کو معیاری فائلوں کے طور پر رکھیں۔

چاہے آپ کسی تصویر کو Base64 string میں اینکوڈ کر رہے ہوں، Base64 کو واپس تصویر میں ڈی کوڈ کر رہے ہوں، یا صرف کسی data URI کا معائنہ کر رہے ہوں، یہ ٹول تیز، پرائیویٹ اور بالکل مفت ہے — ہر تبدیلی آپ کے آلے پر ہی رہتی ہے۔ یہ iPhone، iPad، Android اور تمام جدید ڈیسک ٹاپ براؤزرز پر بغیر کسی انسٹالیشن کے کام کرتا ہے۔

Base64 اینکوڈنگ کیسے کام کرتی ہے

Base64 اینکوڈنگ binary ڈیٹا کو 3 bytes (24 bits) کے گروپوں میں لیتی ہے اور ہر گروپ کو 4 ASCII حروف کے طور پر دوبارہ اینکوڈ کرتی ہے — فی حرف 6 bits — جو 64 حروف کے حروفِ تہجی سے لیے جاتے ہیں: بڑے حروف A–Z، چھوٹے حروف a–z، ہندسے 0–9، نیز + اور /۔ جب ان پٹ کی لمبائی 3 کا گُنا نہ ہو، تو ایک یا دو = padding حروف شامل کیے جاتے ہیں تاکہ آؤٹ پٹ ہمیشہ 4 حروف کا گُنا ہو۔ یہ میکانکی عمل RFC 4648 میں بیان کیا گیا ہے، وہی معیار جو TLS، MIME اور HTTP Basic توثیق استعمال کرتے ہیں۔

یہ تکنیک ایک ٹھوس مسئلہ حل کرنے کے لیے ایجاد کی گئی تھی: ابتدائی SMTP ای میل سرورز صرف 7-bit ASCII متن لے جانے کے لیے ڈیزائن کیے گئے تھے۔ تصاویر جیسی binary فائلوں میں تمام 256 byte اقدار ہوتی ہیں، جن میں سے کئی کو SMTP روٹرز خاموشی سے بگاڑ دیتے یا ہٹا دیتے تھے۔ Base64 ان صوابدیدی bytes کو قابلِ پرنٹ ASCII کے ایک ذیلی مجموعے میں بدل دیتا ہے جسے ہر میل ریلے بغیر چھیڑ چھاڑ کے گزار دیتا ہے۔ اس کی قیمت ایک متوقع 33% سائز میں اضافہ ہے — ہر 3 bytes کی binary 4 حروف بن جاتی ہے، اس لیے ایک 12 KB PNG تقریباً 16 KB متن میں اینکوڈ ہوتی ہے۔

ایک قریبی متعلقہ ویریئنٹ جسے Base64URL کہا جاتا ہے (جو بھی RFC 4648 میں بیان کیا گیا ہے) + کو - سے اور / کو _ سے بدل دیتا ہے، اور آخری = padding کو ہٹا دیتا ہے۔ یہ آؤٹ پٹ کو URLs اور فائل ناموں میں percent-encoding کے بغیر استعمال کے لیے محفوظ بناتا ہے۔ JWT ٹوکنز اور کئی ویب APIs Base64URL استعمال کرتے ہیں؛ معیاری Base64 (+ اور / کے ساتھ) data URIs کے اندر استعمال ہوتا ہے کیونکہ , جداگر پہلے ہی اسے سابقہ MIME type کے اعلان سے الگ کر دیتا ہے۔

Data URIs — مکمل تفصیلات

ایک data URI کی تعریف RFC 2397 کرتا ہے اور یہ data:[<mediatype>][;base64],<data> فارمیٹ کی پیروی کرتا ہے۔ mediatype ایک معیاری MIME type ہے جیسے image/png، image/jpeg، image/svg+xml، یا image/webp۔ اگر اسے چھوڑ دیا جائے تو یہ بطورِ ڈیفالٹ text/plain;charset=US-ASCII ہو جاتا ہے۔ متن پر مبنی ڈیٹا کے لیے آپ ایک charset بھی بیان کر سکتے ہیں — مثلاً data:text/html;charset=utf-8,<h1>Hello</h1> — جو پورے HTML ٹکڑوں یا CSS اسٹائل شیٹس کو data URIs کے طور پر ایمبیڈ کرنے کی اجازت دیتا ہے۔

SVG ایک خاص معاملہ ہے جسے جاننا ضروری ہے: چونکہ SVG XML پر مبنی متن ہے، اسے Base64 اینکوڈنگ کے بغیر ہی ایک data URI میں ایمبیڈ کیا جا سکتا ہے، اس کے بجائے URL encoding استعمال کرتے ہوئے — data:image/svg+xml,%3Csvg …%3E۔ URL-encoded SVG عام طور پر Base64-encoded SVG سے چھوٹا ہوتا ہے کیونکہ Base64 33% اوور ہیڈ شامل کرتا ہے جبکہ URL encoding صرف خصوصی حروف کو پھیلاتا ہے۔ جدید براؤزرز دونوں شکلیں قبول کرتے ہیں، لیکن Base64 SVG کو عالمی طور پر سپورٹ حاصل ہے، بشمول پرانے ای میل کلائنٹس اور Internet Explorer۔

ایک بار جب براؤزر کسی img src، ایک CSS url()، یا ایک iframe src میں کوئی data URI دیکھتا ہے، تو یہ اسے بالکل اسی طرح سمجھتا ہے جیسے کسی بیرونی URL سے حاصل کردہ وسیلہ: یہ MIME type کو parse کرتا ہے، ڈیٹا کو ڈی کوڈ کرتا ہے، اور نتیجہ مناسب renderer کو دیتا ہے۔ کوئی اضافی نیٹ ورک درخواست نہیں کی جاتی۔ براؤزر کی rendering پائپ لائن صرف ایک پہلے سے ڈی کوڈ شدہ byte stream دیکھتی ہے — یہ حقیقت کہ یہ HTTP جواب کے بجائے کسی data URI سے آئی، نیچے کی parsing اور ڈسپلے انجن کے لیے شفاف رہتی ہے۔

ای میل کلائنٹس میں تصاویر اور data URI کا مسئلہ

ای میل کلائنٹس میں تصویر سنبھالنے کا وسیع پیمانے پر مختلف رویہ ہوتا ہے جو براہِ راست اس بات پر اثر انداز ہوتا ہے کہ آپ کو تصاویر کیسے ایمبیڈ کرنی چاہئیں۔ Outlook 2007–2019 کسی حقیقی براؤزر انجن کے بجائے Microsoft Word کے rendering انجن کا استعمال کرتا ہے، اور وہ انجن data URIs کو سپورٹ نہیں کرتا — ایک Base64 inline تصویر بس render نہیں ہوتی۔ Gmail بیرونی طور پر لنک کی گئی تصاویر کو Google کے اپنے سرورز کے ذریعے proxy کرتا ہے (tracking pixels ہٹانے کے لیے)، لیکن HTML ای میل میں inline Base64 تصاویر کو سپورٹ کرتا ہے۔ Apple Mail data URIs کو مکمل طور پر سپورٹ کرتا ہے، جیسا کہ زیادہ تر جدید webmail کلائنٹس۔

قابلِ اعتماد HTML ای میل کے لیے تجویز کردہ طریقہ یہ ہے کہ data URIs کے بجائے Content-ID (CID) ایمبیڈنگ استعمال کریں — تصاویر کو MIME parts کے طور پر منسلک کریں اور انہیں src="cid:image1" کے ساتھ حوالہ دیں۔ CID تصاویر Outlook میں کام کرتی ہیں کیونکہ ای میل کلائنٹ کا renderer انہیں کسی URL یا ڈی کوڈ شدہ data string کے بجائے MIME منسلکہ سے حاصل کرتا ہے۔ تاہم، اگر آپ کی ای میل ایک سنگل فائل HTML دستاویز ہے (رسید، رپورٹ ایکسپورٹ، پیش منظر) نہ کہ ایک multipart MIME پیغام، تو Base64 اب بھی اس واحد فائل میں تصاویر بنڈل کرنے کا واحد طریقہ ہے۔

عملی سفارش: لین دین کی سنگل فائل HTML اور خود کفیل رپورٹس میں Base64 inline تصاویر استعمال کریں جہاں آپ کنٹرول کرتے ہیں کہ فائل کیسے کھولی جائے، اور اگر آپ کے سامعین Outlook استعمال کرتے ہیں تو اس پر ٹیسٹ کریں۔ Mailchimp یا SendGrid جیسے فراہم کنندگان کے ذریعے بھیجی جانے والی بلک ای میل مہمات کے لیے، تصاویر کو CDN پر ہوسٹ کریں اور ان سے لنک کریں — CID طریقہ بڑے پیمانے پر ناقابلِ عمل ہے اور زیادہ تر ESPs بہرحال tracking اور proxy مقاصد کے لیے تصویری لنکس کو دوبارہ لکھتے ہیں۔

کارکردگی کے اثرات اور براؤزر کی حدود

HTTP/1.1 کے دور میں، براؤزرز ایک ہی ڈومین سے بیک وقت کنکشنز کو محدود کرتے تھے (عموماً 6)، اس لیے ہر اضافی image فائل ایک قیمتی کنکشن سلاٹ خرچ کرتی اور TCP handshake اور DNS lookup کی تاخیر شامل کرتی۔ چھوٹی تصاویر کو data URIs کے طور پر inline کرنا ان راؤنڈ ٹرپس کو مکمل طور پر ختم کر دیتا تھا، جو آئیکن سے بھرپور انٹرفیس کے لیے ایک قابلِ پیمائش فائدہ تھا۔ یہ دلیل HTTP/2 کے ساتھ نمایاں طور پر کمزور ہو گئی، جو تمام درخواستوں کو ایک ہی کنکشن پر multiplex کرتا ہے — فی فائل اوور ہیڈ جو کئی چھوٹی بیرونی تصاویر کو سست بناتا تھا، بنیادی طور پر غائب ہو جاتا ہے، جو جدید stacks میں data URIs کے لیے کنکشن بچت کی دلیل کو بہت کم پرکشش بنا دیتا ہے۔

data URI کی لمبائی پر براؤزر کی حدود تاریخی طور پر مختلف رہی ہیں: Internet Explorer 8 نے data URIs کو 32 KB پر محدود کیا، جس نے اسے چھوٹے آئیکنز کے علاوہ کسی بھی چیز سے غیر مطابقت پذیر بنا دیا۔ جدید براؤزرز — Chrome، Firefox، Safari، Edge — کوئی دستاویزی عملی حد عائد نہیں کرتے، لیکن انتہائی لمبے data URIs (کئی میگابائٹ کی تصاویر) اب بھی HTML parser کی کارکردگی کو متاثر کر سکتے ہیں کیونکہ جب parser ان کا سامنا کرتا ہے تو پوری string کو synchronously پڑھنا اور ڈی کوڈ کرنا پڑتا ہے۔ زیادہ اہم بات یہ ہے کہ چونکہ ایک data URI HTML یا CSS دستاویز کا حصہ ہے، اسے آزادانہ طور پر cache نہیں کیا جاتا: ہر page load تصویر کو دوبارہ منتقل اور دوبارہ ڈی کوڈ کرتا ہے، چاہے اس میں کچھ نہ بدلا ہو۔

وسیع پیمانے پر قبول شدہ کارکردگی کی رہنمائی یہ ہے کہ صرف تقریباً 4 KB سے کم تصاویر کو inline کیا جائے — وہ حد جس پر HTTP درخواست کا اوور ہیڈ (TCP راؤنڈ ٹرپ، headers، سرور پروسیسنگ کا وقت) 33% Base64 سائز جرمانے سے زیادہ بھاری ہو جاتا ہے۔ اس حد سے اوپر، ایک بیرونی image فائل جو ایک طویل مدتی Cache-Control: max-age header کے ساتھ پیش کی جائے، دوبارہ دیکھنے پر تقریباً ہمیشہ تیزی سے لوڈ ہوگی۔ webpack، Vite اور Next.js جیسے بلڈ ٹولز بالکل یہی طریقہ کار لاگو کرتے ہیں: وہ اپنی کنفیگر شدہ حد (اکثر 4–8 KB) سے کم اثاثوں کو خودکار طور پر inline کرتے ہیں اور اس سے بڑی کسی بھی چیز کے لیے الگ فائلیں تیار کرتے ہیں۔