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 پیلوڈز، URLs، HTML اور CSS۔ یہ ٹول ٹیکسٹ اور فائلوں دونوں کے لیے Base64 اینکوڈ اور ڈی کوڈ کرتا ہے، اور زیادہ تر مقبول Base64 ویب سائٹس کے برعکس یہ مکمل طور پر آپ کے ڈیوائس پر چلتا ہے۔ آپ جو کچھ بھی پیسٹ یا ڈراپ کرتے ہیں وہ کبھی اپ لوڈ نہیں ہوتا، جو اس وقت اہم ہے جب ڈیٹا کوئی ایکسیس ٹوکن، API key، یا کوئی اور چیز ہو جسے آپ کسی تیسرے فریق کے سرور کو نہیں دینا چاہتے۔

یہ ان معاملات کو سنبھالنے کے لیے بنایا گیا ہے جن میں سادہ ٹولز غلطی کرتے ہیں: مکمل Unicode (بشمول emoji اور غیر لاطینی رسم الخط)، URL-safe Base64URL، MIME اور PEM لائن ریپنگ، اور ایسے ٹیکسٹ کو ڈی کوڈ کرنا جو اصل میں غیر UTF-8 کیریکٹر سیٹ میں اینکوڈ کیا گیا تھا۔

چاہے آپ کسی ای میل اٹیچمنٹ کو ڈی کوڈ کر رہے ہوں، کسی امیج کو data URI میں تبدیل کر رہے ہوں، یا JWT کے پیلوڈ کا معائنہ کر رہے ہوں، سب کچھ فوری طور پر اور مکمل رازداری کے ساتھ ہوتا ہے۔ کوئی سائن اپ نہیں، کوئی حد نہیں، اور کوئی سرور آپ کے ڈیٹا کو کبھی نہیں دیکھتا۔

کسی بھی چیز کو ڈی کوڈ کریں — charset کنٹرول اور معاف کر دینے والے پارسر کے ساتھ

پیسٹ کیا گیا Base64 اکثر بے ترتیب ہوتا ہے: یہ ای میل ریپنگ سے لائن بریکس اٹھا لیتا ہے، ٹرمینل میں اپنی آخری = پیڈنگ کھو دیتا ہے، یا مکمل data: URI کے طور پر آتا ہے۔ ڈی کوڈر یہ سب خود بخود صاف کر دیتا ہے — whitespace ہٹا کر، URL-safe کیریکٹرز قبول کر کے، پیڈنگ بحال کر کے، اور data URIs کھول کر — اور اگر واقعی کوئی چیز غلط ہو تو یہ خاموشی سے ناکام ہونے کے بجائے بالکل ٹھیک کیریکٹر اور پوزیشن کی نشاندہی کرتا ہے۔

چونکہ Base64 خام bytes کو بغیر کسی کیریکٹر سیٹ لیبل کے ذخیرہ کرتا ہے، ڈی کوڈ شدہ ٹیکسٹ خراب دکھائی دے سکتا ہے جب یہ اصل میں UTF-8 نہ ہو۔ Decode as سلیکٹر آپ کو انہی bytes کو UTF-16، Latin-1، Windows-1252، ASCII، Shift_JIS، یا GBK کے طور پر دوبارہ تشریح کرنے دیتا ہے۔ خام bytes کا براہ راست معائنہ کرنے کے لیے Hex ویو پر سوئچ کریں جب آپ بائنری پیلوڈز کو ڈی بگ کر رہے ہوں۔

یہ لچک ان لوگوں کے لیے قیمتی ہے جو پرانے سسٹمز، ای میل کلائنٹس، یا مشرقی ایشیائی سافٹ ویئر سے آنے والے Base64 سٹرنگز کے ساتھ کام کرتے ہیں جو UTF-8 کے بجائے کسی علاقائی اینکوڈنگ کو ڈیفالٹ کے طور پر استعمال کرتے ہیں۔

فائلیں اور امیجز، پریویو اور فوری پیسٹ ہونے والے سنیپٹس کے ساتھ

کوئی فائل ڈراپ کریں، براؤز کرنے کے لیے کلک کریں، یا اپنے کلپ بورڈ سے کوئی امیج بس پیسٹ کر دیں۔ امیجز inline پریویو ہوتی ہیں، اور ٹول اس کے magic bytes سے فائل کی قسم کا پتہ لگاتا ہے — چنانچہ ڈی کوڈ شدہ blob کو درست طور پر PNG، JPEG، GIF، WebP، PDF وغیرہ کے طور پر پہچانا جاتا ہے، اور صحیح ایکسٹینشن کے ساتھ ڈاؤن لوڈ ہوتا ہے۔

اثاثے embed کرنے کے لیے، کسی امیج کو اینکوڈ کریں اور تیار شدہ data URI، کوئی CSS background-image رول، کوئی <img> ٹیگ، یا favicon <link> کاپی کریں — سٹرنگ کو ہاتھ سے جوڑنے کی ضرورت نہیں۔ ڈویلپرز کو بالکل یہی چاہیے ہوتا ہے جب وہ favicons، ای میل لوگوز، یا آئیکن سپرائٹس کو ایک ہی فائل والے پیج میں inline کرتے ہیں۔

Decode موڈ میں ٹول data URI کے prefix سے MIME قسم پڑھتا ہے یا خام bytes سے فائل کی قسم کا پتہ لگاتا ہے، امیجز کو inline پریویو کرتا ہے، اور آپ کو درست ایکسٹینشن کے ساتھ اصل فائل ڈاؤن لوڈ کرنے دیتا ہے۔

یہ دیگر مفت Base64 ٹولز سے بہتر کیوں ہے

بہت سے مفت Base64 ٹولز — بشمول base64decode.org اور base64encode.org جیسی مقبول سائٹس کے ٹولز — آپ کے ان پٹ کو سرور سائیڈ پر پروسیس کرتے ہیں۔ اس کا مطلب ہے کہ آپ کے JWT ٹوکنز، API keys، اور نجی فائل کے مندرجات ایک ریموٹ سرور کو منتقل کیے جاتے ہیں جس پر آپ کا کنٹرول نہیں۔ UtiloKit کا Base64 ٹول آپ کے براؤزر میں 100٪ JavaScript میں چلتا ہے۔ آپ پیج لوڈ ہونے کے بعد انٹرنیٹ سے منقطع بھی ہو سکتے ہیں اور یہ پھر بھی بالکل ٹھیک کام کرتا ہے۔

CyberChef بہترین ہے لیکن سادہ اینکوڈنگ کاموں کے لیے اس کا سیکھنے کا منحنی خط کھڑا ہے۔ base64.guru ٹیکسٹ کو اچھی طرح سنبھالتا ہے لیکن فائلوں کو اپنے سرور پر اپ لوڈ کرتا ہے۔ TinyWow مفت صارفین پر روزانہ کی حدیں لگاتا ہے۔ UtiloKit ای میل مطابقت کے لیے MIME لائن ریپنگ، سرٹیفکیٹس کے لیے PEM فارمیٹنگ، بین الاقوامی ٹیکسٹ کے لیے charset سے آگاہ ڈی کوڈنگ، JWT اور OAuth ٹوکنز کے لیے URL-safe Base64URL سپورٹ، اور ڈی کوڈ شدہ بائنریز کے لیے فائل قسم کا پتہ لگانا پیش کرتا ہے — سب مفت، سب لامحدود، سب نجی۔

iPhone، Android اور کسی بھی ڈیوائس پر کام کرتا ہے — کوئی ایپ درکار نہیں

یہ Base64 اینکوڈر اور ڈی کوڈر مکمل طور پر ریسپانسو ہے اور جدید براؤزر والے ہر ڈیوائس پر کام کرتا ہے۔ iPhone اور Android پر، آپ اپنے کلپ بورڈ سے براہ راست ٹیکسٹ پیسٹ کر سکتے ہیں، Files ایپ یا کیمرہ رول سے فائلیں چن سکتے ہیں، اور اینکوڈ یا ڈی کوڈ شدہ نتیجہ ڈاؤن لوڈ کر سکتے ہیں — یہ سب کچھ بغیر کچھ انسٹال کیے۔ انٹرفیس 375px چوڑائی اور اس سے اوپر کی چھوٹی سکرینوں کے لیے بہتر بنایا گیا ہے۔

چونکہ یہ ٹول لوڈ ہونے کے بعد مکمل طور پر آف لائن چلتا ہے (کوئی سرور کالز نہیں، کوئی انحصار نہیں)، یہ ان حالات میں کام کرتا رہتا ہے جہاں base64decode.org یا CyberChef جیسے ویب پر مبنی ٹولز جدوجہد کر سکتے ہیں — VPN کے اندر، لوڈ ہونے کے بعد airplane موڈ میں، یا محدود نیٹ ورک رسائی والے ڈیوائس پر۔ موبائل پر ڈویلپرز JWT پیلوڈز ڈی کوڈ کر سکتے ہیں، iOS پر انجینئرز data URIs کا معائنہ کر سکتے ہیں، اور کوئی بھی بغیر ڈیسک ٹاپ مشین کے CSS میں امیجز embed کر سکتا ہے۔

Base64 اینکوڈنگ کیسے کام کرتی ہے: مرحلہ وار الگورتھم

Base64 ان پٹ bytes کو تین بائٹ کے حصوں میں گروپ کر کے اور ہر حصے کو چار قابل پرنٹ کیریکٹرز میں تبدیل کر کے کام کرتا ہے۔ سب سے پہلے، خام bytes کو ایک مسلسل بٹ سٹریم کے طور پر رکھا جاتا ہے۔ اس سٹریم کے ہر 6 bits ایک انڈیکس پر میپ ہوتے ہیں جو 64 کیریکٹر والے حروف تہجی میں ہوتا ہے: بڑے A–Z (انڈیکس 0–25)، چھوٹے a–z (26–51)، ہندسے 0–9 (52–61)، + (62)، اور / (63)۔ چونکہ 6 bits 64 قدروں کی نمائندگی کر سکتے ہیں اور 8 bits 256 کی، تین 8-bit bytes (24 bits) کو اینکوڈ کرنا ہمیشہ بالکل چار 6-bit گروپس (بھی 24 bits) دیتا ہے — اور چار قابل پرنٹ کیریکٹرز۔ یہ مقررہ 3-to-4 تبدیلی کا تناسب ہی وجہ ہے کہ Base64 آؤٹ پٹ ہمیشہ ان پٹ سے تقریباً 33٪ بڑا ہوتا ہے۔

ایک عملی مثال الگورتھم کو ٹھوس بنا دیتی ہے۔ لفظ Man کو اینکوڈ کرنا اس کی ASCII قدروں سے شروع ہوتا ہے: M = 77، a = 97، n = 110۔ بائنری میں یہ ہیں 01001101 01100001 01101110۔ 24 bits کے طور پر آخر سے آخر رکھ کر اور چار 6-bit گروپس میں تقسیم کر کے: 010011 (19 → T)، 010110 (22 → W)، 000101 (5 → F)، 101110 (46 → u) — Base64 سٹرنگ TWFu پیدا کرتی ہے۔ جب کل ان پٹ کی لمبائی 3 کا ضرب نہ ہو، تو آخری گروپ کو مکمل 6-bit حد تک پہنچنے کے لیے صفر bits سے پیڈ کیا جاتا ہے، اور ایک یا دو = پیڈنگ کیریکٹرز شامل کیے جاتے ہیں تاکہ یہ اشارہ ہو کہ آخری اینکوڈ شدہ گروپ چھوٹا تھا۔ ایک = کا مطلب ہے آخری ان پٹ گروپ میں 2 bytes تھے؛ دو == کا مطلب ہے صرف 1 byte تھا۔

ڈی کوڈنگ بالکل الٹا عمل کرتی ہے: ہر کیریکٹر کو حروف تہجی میں تلاش کر کے اس کا 6-bit انڈیکس بحال کیا جاتا ہے، چار گروپس کو 24 bits میں جوڑا جاتا ہے، اور ان bits کو واپس تین bytes میں تقسیم کیا جاتا ہے۔ پیڈنگ کیریکٹرز کو رد کر دیا جاتا ہے۔ چونکہ میپنگ ایک سادہ لک اپ ٹیبل ہے جس میں کوئی key اور کوئی state نہیں، ڈی کوڈنگ فوری ہوتی ہے — دریافت کرنے کے لیے کوئی راز نہیں اور brute-force کرنے کے لیے کوئی حساب نہیں۔ یہی وجہ ہے کہ Base64 صفر رازداری فراہم کرتا ہے اور اسے کبھی encryption سے نہیں الجھانا چاہیے۔

Base64 کیوں ایجاد ہوا: SMTP، MIME، اور 7-bit ASCII کا مسئلہ

Base64 کی ضرورت ان فیصلوں میں جڑی ہے جو انٹرنیٹ کے ابتدائی دور میں کیے گئے۔ ای میل پروٹوکول SMTP 1980 کی دہائی کے اوائل میں 7-bit ASCII ٹیکسٹ کے لیے ڈیزائن کیا گیا تھا۔ میل سرورز پیغامات کو ریلے نوڈز سے گزارتے تھے جو ہر byte کا 8واں بٹ ہٹا دیتے تھے — یہ عمل ٹیلی گراف نیٹ ورکس سے وراثت میں ملا تھا۔ بائنری فائلیں، امیجز، اور کوئی بھی غیر انگریزی ٹیکسٹ جو 127 سے اوپر byte قدریں استعمال کرتا تھا، منتقلی کے دوران خاموشی سے خراب ہو جاتا تھا۔ ای میل کے ذریعے تصویر یا پروگرام executable بھیجنا خام bytes کے ساتھ بس ناممکن تھا۔

MIME (Multipurpose Internet Mail Extensions)، جو 1992 میں RFC 2045 میں معیاری بنایا گیا، نے اس کا حل content-transfer encodings کا ایک سیٹ متعین کر کے نکالا جس نے بائنری ڈیٹا کو صرف ASCII والے انفراسٹرکچر کے لیے محفوظ بنا دیا۔ Base64 کو MIME کی مرضی کے مطابق بائنری کے لیے اینکوڈنگ کے طور پر مقرر کیا گیا کیونکہ یہ ہر byte کو محفوظ 7-bit ASCII رینج کے کیریکٹرز میں بدل دیتا ہے، ہر میل ریلے سے بچ نکلتا ہے جو ہائی بٹ کو ہٹاتا ہے۔ یہی بنیادی مسئلہ — ایک ٹیکسٹ پر مبنی چینل جو بھروسے سے صوابدیدی bytes نہیں لے جا سکتا — ویب سٹیک میں بار بار ظاہر ہوتا ہے: HTTP ہیڈرز خام bytes پر مشتمل نہیں ہو سکتے، cookies ASCII کے ایک ذیلی سیٹ تک محدود ہیں، JSON اور XML ٹیکسٹ فارمیٹس ہیں جہاں NUL bytes یا غیر escape شدہ بائنری پارسنگ کو توڑ دے گی، اور HTML attributes میں angle brackets یا quotes بغیر escape کے نہیں ہو سکتے۔ Base64 ان تمام رکاوٹوں کا عالمگیر جواب ہے کیونکہ یہ کسی بھی بائنری تسلسل کو ایک ایسی سٹرنگ میں بدل دیتا ہے جسے کوئی بھی ٹیکسٹ پر مبنی سسٹم بغیر ترمیم کے ذخیرہ اور آگے بھیج سکتا ہے۔

آج SMTP زیادہ تر 8-bit صاف ہے اور بہت سے ای میل سرورز 8BITMIME ایکسٹینشن کو سپورٹ کرتے ہیں، لیکن اٹیچمنٹس کی Base64 اینکوڈنگ برقرار ہے کیونکہ MIME معیار اب تک لکھے گئے ہر میل کلائنٹ اور سرور میں گہرائی سے شامل ہے۔ وہ اینکوڈنگ جس نے 1980 کی دہائی کی ای میل کو ٹھیک کیا، اب JWTs، data URIs، SSH keys، TLS سرٹیفکیٹس، HTTP Basic Auth، اور درجنوں دیگر جدید معیارات میں بُنی ہوئی ہے — سب اس لیے کہ وہی 7-bit حفاظتی تقاضا نئے سیاق و سباق میں دوبارہ ابھرتا رہتا ہے۔

Base64 اقسام: معیاری، URL-safe، MIME، اور پیڈنگ کے بغیر

کوئی واحد Base64 نہیں ہے — کئی قریبی متعلق اقسام ہیں جو اپنے حروف تہجی کے دو کیریکٹرز میں اور لائن بریکس اور پیڈنگ کو سنبھالنے کے طریقے میں مختلف ہیں۔ معیاری Base64 (RFC 4648 §4) 62ویں اور 63ویں کیریکٹرز کے طور پر + اور / استعمال کرتا ہے اور = پیڈنگ کی ضرورت ہوتی ہے۔ یہ وہ قسم ہے جو MIME ای میل اٹیچمنٹس، PEM سرٹیفکیٹس، اور زیادہ تر عمومی مقصد کی اینکوڈنگ لائبریریوں کے ذریعے استعمال ہوتی ہے۔ + اور / کیریکٹرز ہر جگہ رگڑ کا ذریعہ ہیں۔

URL-safe Base64 (RFC 4648 §5، جسے Base64url بھی کہا جاتا ہے) + کو - اور / کو _ سے بدل دیتا ہے۔ یہ اس لیے اہم ہے کہ URL query strings میں + کا مطلب space ہوتا ہے اور / path سیپریٹر ہے — URL میں شامل ایک معیاری Base64 سٹرنگ غلط سمجھی جائے گی یا اسے percent-encoding درکار ہو گی، جس سے یہ لمبی اور پڑھنے میں مشکل ہو جائے گی۔ Base64url وہ قسم ہے جو JWT تصریح (RFC 7519)، OAuth 2.0 PKCE، اور کسی بھی ایسے سیاق و سباق کی طرف سے لازمی ہے جہاں اینکوڈ شدہ سٹرنگ کسی URL، فائل نام، یا HTTP ہیڈر میں ظاہر ہوتی ہے۔ JWT مزید طور پر آخری = پیڈنگ کو مکمل طور پر گرا دیتا ہے، کیونکہ JWT سیگمنٹ کی لمبائی مجموعی ساخت سے اخذ کی جا سکتی ہے، اور URLs میں پیڈنگ کیریکٹرز کو بصورت دیگر %3D کے طور پر percent-encode کرنا پڑتا ہے۔

MIME Base64 (RFC 2045) معیاری Base64 ہے جس میں ہر 76 کیریکٹرز کے بعد لازمی لائن بریک ہوتا ہے، CRLF (\r\n) استعمال کرتے ہوئے۔ یہ ای میل لائنوں کو ابتدائی میل سسٹمز کی طرف سے عائد کردہ روایتی 76 کیریکٹر چوڑائی کے اندر رکھنے کے لیے درکار تھا۔ PEM (وہ فارمیٹ جو X.509 سرٹیفکیٹس اور SSH keys کے لیے استعمال ہوتا ہے) وہی 64 کیریکٹر لائن لمبائی -----BEGIN CERTIFICATE----- جیسے ہیڈرز کے ساتھ استعمال کرتا ہے۔ سسٹمز کے درمیان تبادلے میں قسم اہم ہے: ایک معیاری ڈی کوڈر کو دی گئی URL-safe سٹرنگ - اور _ کیریکٹرز پر ناکام ہو جائے گی، اور ایک ایسے ڈی کوڈر کو دی گئی MIME-ریپ شدہ سٹرنگ جو newlines نہیں ہٹاتا، لائن بریکس پر ناکام ہو جائے گی۔ ایک مضبوط ڈی کوڈر — جیسا کہ اس ٹول میں ہے — تمام اقسام کو خود بخود معیاری بنا دیتا ہے۔

Base64 عملی طور پر کہاں ظاہر ہوتا ہے — اور یہ encryption کیوں نہیں

Base64 زیادہ تر ڈویلپرز کے سمجھنے سے زیادہ جگہوں پر شامل ہے۔ JWT (JSON Web Tokens) اپنے ہیڈر اور پیلوڈ دونوں کو Base64url کے طور پر اینکوڈ کرتے ہیں — کسی بھی JWT کو ڈی کوڈر میں پیسٹ کریں اور آپ فوراً claims (user ID، roles، expiry) سادہ ٹیکسٹ میں پڑھ سکتے ہیں۔ signature چھیڑ چھاڑ کو روکتا ہے، لیکن پیلوڈ encrypt نہیں ہوتا؛ جو کوئی بھی JWT کو روکتا ہے وہ اس میں موجود ہر چیز پڑھ سکتا ہے۔ HTTP Basic Authentication username:password کو Base64 کے طور پر اینکوڈ کرتا ہے اور اسے Authorization ہیڈر میں بھیجتا ہے — سادہ HTTP پر یہ مکمل طور پر غیر محفوظ ہے کیونکہ پاس ورڈ آسانی سے بحال ہو جاتا ہے۔ Basic Auth صرف HTTPS پر محفوظ ہے، جہاں TLS پورے request کو encrypt کرتا ہے بشمول ہیڈر کے۔

Data URIs (src="data:image/png;base64,...") فائل کے مندرجات کو براہ راست HTML یا CSS میں embed کرتے ہیں، جس سے چھوٹے اثاثوں کے لیے ایک HTTP راؤنڈ ٹرپ ختم ہو جاتا ہے۔ Favicons، inline SVG آئیکنز، اور چھوٹے UI سپرائٹس عام امیدوار ہیں۔ ~/.ssh/authorized_keys میں SSH پبلک keys Base64-اینکوڈ شدہ DER ڈھانچے ہیں۔ PEM فارمیٹ میں X.509 سرٹیفکیٹس ہیڈر اور فٹر لائنوں کے ساتھ Base64 ہیں۔ ای میل اٹیچمنٹس جب سے MIME ایجاد ہوا تب سے Base64-اینکوڈ ہوتے آئے ہیں۔ JSON یا XML میں بائنری blobs ذخیرہ کرنا — REST APIs میں عام جو فائل مواد کا تبادلہ کرتے ہیں — Base64 استعمال کرتا ہے کیونکہ کسی بھی فارمیٹ میں مقامی بائنری قسم نہیں ہے۔

Base64 کے بارے میں سب سے اہم غلط فہمی یہ ہے کہ یہ کسی قسم کی سلامتی فراہم کرتا ہے۔ ایسا نہیں ہے۔ Base64 ایک الٹنے کے قابل اینکوڈنگ ہے جس کا ایک عوامی، مقررہ الگورتھم ہے اور کوئی key نہیں — ڈی کوڈنگ ایک لک اپ ٹیبل کا عمل ہے جسے کوئی بھی پروگرامر دس لائنوں میں لاگو کر سکتا ہے۔ کسی پاس ورڈ یا API key کو Base64-اینکوڈ کر کے چھپانا بالکل صفر تحفظ فراہم کرتا ہے؛ خودکار سکینرز credential-harvesting حملوں کے حصے کے طور پر سورس کوڈ اور کنفیگریشن فائلوں میں Base64 سٹرنگز کو معمول کے مطابق ڈی کوڈ کرتے ہیں۔ اگر ڈیٹا کو خفیہ رکھنا ضروری ہے، تو اسے AES یا اسی طرح کے cipher سے encrypt کریں اس سے پہلے کہ (اختیاری طور پر) ciphertext کو منتقلی کے لیے Base64 کے طور پر اینکوڈ کریں۔ encryption سلامتی فراہم کرتا ہے؛ Base64 صرف محفوظ ASCII منتقلی فراہم کرتا ہے۔

Frequently asked questions

Base64 کیا ہے اور یہ کس لیے استعمال ہوتا ہے؟

Base64 ایک اینکوڈنگ سکیم ہے جو بائنری ڈیٹا — فائلیں، امیجز، یا کوئی بھی bytes — کو صرف 64 قابل پرنٹ ASCII کیریکٹرز (A–Z، a–z، 0–9، +، /) کا استعمال کرتے ہوئے ظاہر کرتی ہے۔ یہ بائنری کو صرف ٹیکسٹ والے چینلز کے ذریعے محفوظ طریقے سے منتقل کرنے کے لیے استعمال ہوتا ہے: HTML، CSS، یا ای میل میں امیجز embed کرنا، JSON یا XML کے اندر بائنری ذخیرہ کرنا، JWT ہیڈر اور پیلوڈ سیگمنٹس اینکوڈ کرنا، اور query strings میں قدریں پاس کرنا۔ یہ ان سسٹمز کا مسئلہ حل کرتا ہے جو خام bytes کو ہٹا، تبدیل یا خراب کر دیتے ہیں، ہر چیز کو سادہ ASCII ٹیکسٹ میں بدل کر جو منتقلی میں بغیر ترمیم کے بچ جاتا ہے۔

کیا Base64 encryption ہے — کیا یہ محفوظ ہے؟

نہیں۔ Base64 اینکوڈنگ ہے، encryption یا hashing نہیں — یہ کوئی key استعمال نہیں کرتا اور کوئی بھی اسے فوری طور پر کسی بھی Base64 ڈی کوڈر سے ڈی کوڈ کر سکتا ہے، بشمول اس کے۔ یہ صفر رازداری فراہم کرتا ہے اور اسے کبھی پاس ورڈز، API keys، یا نجی ڈیٹا کی حفاظت کے لیے استعمال نہیں کرنا چاہیے۔ Base64 ایک منتقلی اینکوڈنگ ہے، سلامتی کا اقدام نہیں۔ اگر آپ کو حساس ڈیٹا کی حفاظت کرنی ہے، تو پہلے اسے encrypt کریں (AES، RSA، وغیرہ) اور صرف پھر اختیاری طور پر ciphertext کو محفوظ منتقلی کے لیے Base64-اینکوڈ کریں — لیکن حفاظت encryption کر رہا ہے، اینکوڈنگ نہیں۔

کیا یہ Base64 اینکوڈر اور ڈی کوڈر مفت ہے؟

جی ہاں، بالکل مفت، بغیر کسی سائن اپ کے اور ٹیکسٹ کی لمبائی یا فائل کے سائز پر کوئی حد نہیں۔ TinyWow مفت صارفین کو روزانہ چند تبدیلیوں تک محدود کرتا ہے، Smallpdf آپ کو روزانہ 2 کاموں پر روک دیتا ہے، اور بہت سی سائٹس کو مکمل خصوصیات کھولنے کے لیے اکاؤنٹس درکار ہوتے ہیں۔ UtiloKit کے Base64 ٹول پر کوئی روزانہ کی حدیں نہیں، کوئی اکاؤنٹ کی شرط نہیں، اور کوئی paywalls نہیں — یہ ہر اینکوڈنگ اور ڈی کوڈنگ آپریشن کے لیے مفت ہے جس کی آپ کو کبھی ضرورت ہو گی۔ کوئی ای میل ایڈریس نہیں، کوئی کریڈٹ کارڈ نہیں، کچھ نہیں۔

کیا یہاں حساس ڈیٹا اینکوڈ کرنا محفوظ ہے؟

جی ہاں۔ سب کچھ آپ کے براؤزر میں پروسیس ہوتا ہے — ٹیکسٹ، فائلیں، اور امیجز کبھی سرور پر اپ لوڈ نہیں ہوتیں — چنانچہ ٹوکنز یا credentials جیسا حساس مواد بھی آپ کے ڈیوائس پر رہتا ہے۔ بہت سی مقبول Base64 سائٹس آپ کے ان پٹ کو اپنے سرورز پر اپ لوڈ کرتی ہیں؛ یہ کبھی نہیں کرتی۔ آپ آف لائن اینکوڈ کر کے اس کی تصدیق کر سکتے ہیں: یہ پھر بھی کام کرتا ہے۔

Base64 ایک یا دو = نشانات پر کیوں ختم ہوتا ہے؟

= کیریکٹرز پیڈنگ ہیں۔ Base64 ان پٹ کو 3 بائٹ کے گروپوں میں اینکوڈ کرتا ہے جو ہر ایک 4 کیریکٹرز بنتے ہیں؛ جب آخری گروپ چھوٹا ہو، تو = نشانات آؤٹ پٹ کو 4 کے ضرب والی لمبائی تک پیڈ کرتے ہیں۔ ایک = کا مطلب ہے آخری گروپ میں 2 bytes تھے، دو = نشانات کا مطلب ہے اس میں 1 byte تھا۔ پیڈنگ کوئی ڈیٹا نہیں رکھتی، اس لیے یہ ٹول ڈی کوڈنگ کے وقت کوئی بھی غائب = خود بخود بحال کر دیتا ہے۔

Base64 میں کون سے کیریکٹرز کی اجازت ہے؟

معیاری Base64 A–Z، a–z، 0–9 کے علاوہ علامات + اور / استعمال کرتا ہے، اور پیڈنگ کے لیے = — کل 65 کیریکٹرز۔ اس کے علاوہ کچھ بھی (spaces، لائن بریکس، دیگر رموز اوقاف) حروف تہجی کا حصہ نہیں۔ URL-safe قسم + اور / کو - اور _ سے بدل دیتی ہے۔ یہ ڈی کوڈر پھر بھی whitespace، newlines، اور URL-safe کیریکٹرز کو برداشت کرتا ہے اور آپ کو کسی بھی ایسے کیریکٹر کی درست پوزیشن بتاتا ہے جسے یہ قبول نہیں کر سکتا۔

Base64 کے نقصانات کیا ہیں؟

Base64 ڈیٹا کو تقریباً 33٪ بڑا کر دیتا ہے کیونکہ ہر 3 bytes 4 کیریکٹرز بن جاتے ہیں — یہ اضافی بوجھ HTTP responses، HTML فائلوں، یا CSS bundles میں تیزی سے بڑھتا ہے جہاں پیلوڈ کا سائز کارکردگی پر اثر ڈالتا ہے۔ یہ انسان کے پڑھنے کے قابل نہیں، جو کوڈ ریویوز اور ڈی بگنگ کو مشکل بنا دیتا ہے جب سورس میں Base64 سٹرنگز ظاہر ہوتی ہیں۔ یہ کوئی error detection یا checksumming فراہم نہیں کرتا، اس لیے ایک واحد خراب کیریکٹر خاموشی سے غلط آؤٹ پٹ پیدا کرتا ہے۔ اور یہ صفر رازداری پیش کرتا ہے — جو کوئی بھی سٹرنگ دیکھتا ہے وہ اسے سیکنڈوں میں ڈی کوڈ کر سکتا ہے۔ یہ صرف ٹیکسٹ والے چینلز کے ذریعے بائنری منتقل کرنے کے لیے صحیح انتخاب ہے، لیکن یہ compression نہیں اور یہ سلامتی نہیں۔ بڑے پیلوڈز کے لیے، اس کے بجائے مناسب Content-Type ہیڈرز کے ساتھ بائنری منتقلی استعمال کریں۔

کیا Base64 اور UTF-8 ایک ہی چیز ہیں؟

نہیں — یہ بالکل مختلف مسائل حل کرتے ہیں۔ UTF-8 ایک کیریکٹر اینکوڈنگ ہے جو انسان کے پڑھنے کے قابل ٹیکسٹ (حروف، emoji، علامات) کو bytes میں بدلتی ہے۔ Base64 پھر کوئی بھی bytes — بشمول UTF-8 bytes — لیتا ہے اور انہیں صرف ٹیکسٹ منتقلی کے لیے محفوظ سادہ ASCII کیریکٹرز میں بدل دیتا ہے۔ دونوں مل کر تہہ بناتے ہیں: کسی Unicode سٹرنگ کو Base64-اینکوڈ کرنے کے لیے آپ پہلے اسے UTF-8 bytes میں بدلتے ہیں، پھر ان bytes کو Base64 کے طور پر اینکوڈ کرتے ہیں۔ UTF-8 مرحلہ چھوڑنا سادہ Base64 ٹولز میں سب سے عام bug ہے — وہ اس کے بجائے JavaScript کی داخلی UTF-16 نمائندگی پر کام کرتے ہیں، بنیادی ASCII سے باہر کسی بھی چیز کے لیے خراب آؤٹ پٹ پیدا کرتے ہیں۔ یہ ٹول ہمیشہ Unicode ٹیکسٹ کو پہلے UTF-8 میں بدلتا ہے، اس لیے emoji اور ہر غیر لاطینی رسم الخط درست طور پر اینکوڈ اور ڈی کوڈ ہوتا ہے۔

کیا Base64 کوئی پروگرامنگ یا کوڈنگ زبان ہے؟

نہیں۔ Base64 ایک ڈیٹا اینکوڈنگ سکیم ہے، پروگرامنگ یا markup زبان نہیں — چلانے، compile یا interpret کرنے کے لیے کچھ نہیں۔ یہ بس ایک الٹنے کے قابل الگورتھم ہے جو صوابدیدی بائنری ڈیٹا کو 64 قابل پرنٹ ASCII کیریکٹرز کے ایک مقررہ سیٹ میں اور واپس بدل دیتا ہے۔ آپ اسے کسی بھی زبان (JavaScript، Python، Go، Java، وغیرہ) میں لکھے گئے پروگراموں کے اندر ایک تبدیلی کے قدم کے طور پر استعمال کرتے ہیں لیکن Base64 خود کوئی زبان نہیں۔ اسے hexadecimal نوٹیشن کی طرح سمجھیں — ایک نمائندگی کا فارمیٹ، زبان نہیں۔

Base64URL کیا ہے اور مجھے اسے کب استعمال کرنا چاہیے؟

Base64URL ایک URL- اور فائل نام کے لیے محفوظ قسم ہے جو + کیریکٹر کو - اور / کیریکٹر کو _ سے بدل دیتی ہے، اور یہ = پیڈنگ کیریکٹرز کو مکمل طور پر گرا دیتی ہے۔ یہ اس لیے اہم ہے کہ معیاری + اور / کے URLs میں خاص معنی ہوتے ہیں — انہیں براؤزرز اور سرورز غلط سمجھیں گے یا percent-encode کریں گے۔ Base64URL کو JWT ہیڈر اور پیلوڈ سیگمنٹس، OAuth ٹوکنز، query-string parameters، اور فائل ناموں کے لیے استعمال کریں جہاں آپ ایک محفوظ، پڑھنے کے قابل سٹرنگ چاہتے ہیں۔ اس ٹول میں URL-safe موڈ ٹوگل کریں اور یہ معیاری Base64 اور URL-safe Base64URL دونوں کو خود بخود اینکوڈ اور ڈی کوڈ کرتا ہے، دونوں طرح پیڈنگ سنبھالتے ہوئے۔

کیا میں فائلوں اور امیجز کو Base64 میں تبدیل کر سکتا ہوں؟

جی ہاں۔ کوئی بھی فائل یا امیج ڈراپ یا پیسٹ کریں تاکہ اس کی Base64 سٹرنگ یا data URI حاصل کریں، امیج اقسام کے لیے inline پریویو کے ساتھ۔ ٹول CSS background-image رولز، HTML img src attributes، اور favicon link tags کے لیے تیار پیسٹ ہونے والے سنیپٹس تیار کرتا ہے، تاکہ آپ کو data URI سٹرنگ ہاتھ سے تعمیر نہ کرنی پڑے۔ Decode موڈ میں یہ data URI prefix سے MIME قسم پڑھتا ہے یا خام bytes (magic bytes) سے فائل کی قسم کا پتہ لگاتا ہے، امیجز کو inline پریویو کرتا ہے، اور آپ کو صحیح ایکسٹینشن بحال کر کے اصل فائل ڈاؤن لوڈ کرنے دیتا ہے۔ PNG، JPG، SVG، WebP، GIF، PDF اور مزید کے ساتھ کام کرتا ہے۔

کیا یہ Unicode اور emoji کو درست طریقے سے سنبھالتا ہے؟

جی ہاں۔ اینکوڈنگ UTF-8 کا استعمال کرتے ہوئے Unicode-safe ہے، اس لیے زیر و بم والے کیریکٹرز، عربی، چینی، جاپانی، کورین، اور emoji سب بغیر خرابی کے درست طریقے سے round-trip کرتے ہیں۔ یہ سادہ Base64 ٹولز میں سب سے عام ناکامی ہے: وہ پہلے مناسب UTF-8 bytes میں تبدیل کرنے کے بجائے JavaScript کی داخلی UTF-16 سٹرنگ نمائندگی پر کام کرتے ہیں، بنیادی ASCII سے باہر کسی بھی چیز کے لیے خراب آؤٹ پٹ پیدا کرتے ہیں۔ یہ ٹول پہلے UTF-8 میں تبدیل کرتا ہے، اس لیے ہر کیریکٹر رسم الخط یا زبان سے قطع نظر درست طریقے سے اینکوڈ اور ڈی کوڈ ہوتا ہے۔

میرا ڈی کوڈ شدہ ٹیکسٹ خراب دکھائی دیتا ہے — کیا میں اسے ٹھیک کر سکتا ہوں؟

جی ہاں۔ Base64 کوئی charset معلومات نہیں رکھتا، اس لیے ایسا ٹیکسٹ جو اصل میں غیر UTF-8 charset میں اینکوڈ کیا گیا تھا، UTF-8 کے طور پر ڈی کوڈ ہونے پر خراب دکھائی دے سکتا ہے۔ «Decode as» سلیکٹر کا استعمال کر کے انہی bytes کو UTF-16 (big-endian اور little-endian دونوں)، Latin-1 (ISO-8859-1)، Windows-1252، ASCII، Shift_JIS (جاپانی)، یا GBK (سادہ چینی) کے طور پر دوبارہ تشریح کریں جب تک ٹیکسٹ درست نہ پڑھا جائے۔ یہ ان Base64 سٹرنگز کے لیے سب سے زیادہ اہم ہے جو پرانے سسٹمز، ای میل کلائنٹس، یا مشرقی ایشیائی سافٹ ویئر سے آئیں جو UTF-8 کے بجائے علاقائی اینکوڈنگ کو ڈیفالٹ کرتے ہیں۔

میرا Base64 ڈی کوڈ کیوں نہیں ہو رہا — یہ invalid کہتا ہے؟

سب سے عام وجوہات سے شروع کریں: اضافی whitespace یا newlines (یہ ڈی کوڈر انہیں خود بخود ہٹا دیتا ہے)، + اور / کے بجائے - اور _ جیسے URL-safe کیریکٹرز (بھی خود بخود سنبھالے جاتے ہیں)، اور آخر میں غائب = پیڈنگ (خود بخود بحال ہو جاتی ہے)۔ اگر سٹرنگ پھر بھی ناکام ہو، تو ممکنہ طور پر آپ کے پاس Base64 حروف تہجی سے باہر کوئی کیریکٹر ہے — کوئی space، percent نشان، کوئی Unicode کیریکٹر، یا کوئی بھٹکی ہوئی HTML entity۔ ڈی کوڈر آپ کو بالکل بتاتا ہے کہ کون سا کیریکٹر invalid ہے اور سٹرنگ میں اس کی پوزیشن کیا ہے تاکہ آپ اسے تلاش اور ٹھیک کر سکیں۔ سورس سے خام سٹرنگ دوبارہ کاپی کریں، کیونکہ کاپی پیسٹ بعض اوقات پوشیدہ Unicode کیریکٹرز یا smart quotes متعارف کراتا ہے جو درست لگتے ہیں لیکن Base64 نہیں ہوتے۔

یہ TinyWow یا it-tools جیسے دیگر Base64 ٹولز کے مقابلے میں کیسا ہے؟

TinyWow اور Smallpdf بنیادی طور پر PDF/امیج ٹولز ہیں جو فائلوں کو اپنے سرورز پر اپ لوڈ کرتے ہیں۔ it-tools.tech کا Base64 ٹول مضبوط ہے لیکن یہ ایک self-hosted ایپ ہے۔ یہاں کلیدی فرق یہ ہے کہ اینکوڈنگ اور ڈی کوڈنگ مکمل طور پر آپ کے براؤزر میں ہوتی ہے — آپ کا ڈیٹا کبھی کہیں منتقل نہیں ہوتا۔ اس کے علاوہ، یہ ٹول charset انتخاب، MIME لائن ریپنگ، فائل پریویو، اور URL-safe Base64 کو ایک ہی جگہ سنبھالتا ہے، بغیر کسی اکاؤنٹ کی شرط کے۔

فوری غلطی کے اشاروں کے ساتھ JSON کو خوبصورت بنائیں، منی فائی اور تصدیق کریں۔

ڈویلپر