JSON ফরম্যাটার ও ভ্যালিডেটর
JSON বিউটিফাই, ভ্যালিডেট বা মিনিফাই করতে পেস্ট করুন। অবৈধ JSON-কে সঠিক লাইন ও কলাম পর্যন্ত চিহ্নিত করা হয়। সবকিছু আপনার ব্রাউজারে চলে — কিছুই আপলোড হয় না। সর্বশেষ পর্যালোচনা 2026-06-19.
JSON ফরম্যাটার কীভাবে ব্যবহার করবেন
- আপনার JSON ইনপুট বক্সে পেস্ট করুন।
- এটি প্রিটি-প্রিন্ট করতে ফরম্যাট / বিউটিফাই-এ ক্লিক করুন (2-স্পেস, 4-স্পেস বা ট্যাব ইনডেন্ট বেছে নিন), ফাঁকা জায়গা সরাতে মিনিফাই, বা শুধু যাচাই করতে ভ্যালিডেট।
- JSON অবৈধ হলে, বার্তাটি সমস্যার সঠিক লাইন ও কলাম দেখায়।
- ফলাফলটি কপি বা ডাউনলোড করুন।
ফরম্যাট বনাম ভ্যালিডেট বনাম মিনিফাই
ভ্যালিডেট করা যাচাই করে আপনার টেক্সট সুগঠিত (well-formed) JSON কিনা। ফরম্যাট করা (বিউটিফাই) বৈধ JSON-কে আবার ইনডেন্ট করে যাতে একজন মানুষ নেস্টেড গঠন পড়তে পারে। মিনিফাই করা প্রতিটি অপ্রয়োজনীয় স্পেস ও নিউলাইন সরিয়ে দেয় যাতে পেলোড যতটা সম্ভব ছোট হয় — নেটওয়ার্কে JSON পাঠানোর বা তা এমবেড করার আগে উপযোগী। এদের কোনোটিই আপনার ডেটা বদলায় না: কি, ভ্যালু, টাইপ ও কি-অর্ডার ঠিক যেমন লেখা হয়েছিল তেমনই থাকে; শুধু ফাঁকা জায়গা ভিন্ন হয়।
JSON অবৈধ হওয়ার সাধারণ কারণ
- ট্রেইলিং কমা —
{"a":1,}অবৈধ; JSON শেষ আইটেমের পরে কোনো কমা মানে না। - সিঙ্গল কোট — স্ট্রিং ও কি-তে
"ডবল কোট"থাকতে হবে, কখনো'নয়। - কোট ছাড়া কি —
{name:"x"}-কে{"name":"x"}হতে হবে। - কমেন্ট — JSON-এ কোনো
//বা/* */কমেন্ট নেই। - ভুল লিটারাল — বুলিয়ান ও null ভ্যালু লোয়ারকেসে হতে হবে (
true,false,null); কেবল-JavaScript কীওয়ার্ড বৈধ JSON নয়। - অমিল ব্র্যাকেট — প্রতিটি
{ও[-এর নিজের সমাপনী সঙ্গী প্রয়োজন।
এটি কি ব্যক্তিগত?
হ্যাঁ। এই টুলটি আপনার ব্রাউজারের নেটিভ JSON.parse ও JSON.stringify ব্যবহার করে —
কিছুই কোনো সার্ভারে পাঠানো হয় না, তাই অভ্যন্তরীণ API রেসপন্স, টোকেন বা কনফিগ পেস্ট করা নিরাপদ। পৃষ্ঠা
লোড হওয়ার পরে এটি অফলাইনেও কাজ করে।
JSON কী, এবং এটি কোথা থেকে এসেছে?
JSON (JavaScript Object Notation) কাঠামোবদ্ধ ডেটা আদান-প্রদানের জন্য একটি হালকা, টেক্সট-ভিত্তিক ফরম্যাট। এটির নাম দিয়েছিলেন ও জনপ্রিয় করেছিলেন Douglas Crockford, যিনি 2002 সালে json.org ডোমেন নিবন্ধন করেন এবং সেখানে এর ব্যাকরণ প্রকাশ করেন। JSON-এর সিনট্যাক্স JavaScript ভাষার অবজেক্ট ও অ্যারে লিটারাল থেকে নেওয়া (বিশেষত 1999 সালের ECMAScript 3 মানদণ্ড থেকে), তবে JSON নিজে ভাষা-নিরপেক্ষ: প্রায় প্রতিটি প্রোগ্রামিং ভাষার জন্য পার্সার ও সিরিয়ালাইজার রয়েছে। ঠিক এ কারণেই এটি একটি ব্রাউজার, একটি মোবাইল অ্যাপ ও একটি সার্ভার — প্রায়শই তিনটি ভিন্ন ভাষায় লেখা — এর মধ্যে পরস্পর কথা বলার ডিফল্ট উপায় হয়ে উঠেছে।
JSON প্রথম IETF স্পেসিফিকেশন হিসেবে লেখা হয় RFC 4627-এ (2006)। পরে এটিকে অক্টোবর 2013-তে ECMA-404 হিসেবে একটি আনুষ্ঠানিক, মানদণ্ড-সংস্থার ব্যাকরণ দেওয়া হয়, এবং বর্তমান প্রামাণিক স্পেসিফিকেশন হলো RFC 8259 (2017), যা ইন্টারনেট স্ট্যান্ডার্ড STD 90 হিসেবেও প্রকাশিত। RFC 8259 একটি নিয়ম স্পষ্ট করেছে যা পুরনো নথি ঝাপসা রেখে দিয়েছিল: সিস্টেমের মধ্যে আদান-প্রদান করা JSON টেক্সট UTF-8-এ এনকোড করতে হবে। দুটি জীবন্ত স্পেসিফিকেশন, ECMA-404 ও RFC 8259, ইচ্ছাকৃতভাবে অভিন্ন রাখা হয়েছে, এবং এদের সম্পাদকরা একমত যে কখনো কোনো একটিতে পরিবর্তন হলে দুটিকেই একসাথে আপডেট করা হবে।
JSON-এর ছয়টি ডেটা টাইপ
কোনো JSON নথিতে প্রতিটি ভ্যালু ঠিক ছয়টি টাইপের একটি — এর বাইরে কিছু নেই:
- Object — ব্রেসে মোড়া
"key": valueজোড়ার একটি অসজ্জিত সমষ্টি। কি অবশ্যই ডবল-কোটেড স্ট্রিং হতে হবে। - Array — বর্গ-বন্ধনীতে মোড়া ভ্যালুর একটি সজ্জিত তালিকা। ভ্যালু মিশ্র টাইপের হতে পারে।
- String — ডবল কোটে টেক্সট, ব্যাকস্ল্যাশ এস্কেপ যেমন
\n,\t,\"ও\uXXXXসহ। - Number — একটি দশমিক সংখ্যা যেমন
42,-3.14বা6.022e23। কোনো আলাদা ইন্টিজার টাইপ নেই, এবংNaN,Infinityও অগ্রণী শূন্য (leading zeros) অনুমোদিত নয়। - Boolean — লোয়ারকেস লিটারাল
trueবাfalse। - Null — লোয়ারকেস লিটারাল
null, অর্থাৎ "কোনো ভ্যালু নেই"।
একটি JSON নথি কেবল এই টাইপগুলোর একটির একটি ভ্যালু — সবচেয়ে সাধারণভাবে শীর্ষ স্তরে একটি অবজেক্ট বা একটি
অ্যারে, যদিও RFC 8259 যেকোনো ভ্যালুকে (এমনকি একটি একক true বা একটি একক সংখ্যা) একটি সম্পূর্ণ
JSON টেক্সট হিসেবে একা দাঁড়ানোর অনুমতি দেয়।
JSON-কে কেন এত কঠোর হতে হয়
JSON ইচ্ছাকৃতভাবে JavaScript সিনট্যাক্সের একটি কঠোর উপসমষ্টি (subset) — এবং কোডে আপনি যেসব অবজেক্ট
লেখেন তার চেয়েও কঠোর। সেই কঠোরতা একটি বৈশিষ্ট্য: একটি অনমনীয় ব্যাকরণ মানে প্রতিটি অনুবর্তী পার্সার কোনো
নথিকে একইভাবে পড়ে, কোনো অস্পষ্টতা ছাড়াই। যেসব নিয়ম মানুষকে সবচেয়ে বেশি বিভ্রান্ত করে সেগুলো এই ডিজাইনের
সরাসরি ফলাফল। কোনো কমেন্ট নেই — Crockford সেগুলো ইচ্ছাকৃতভাবে সরিয়ে দিয়েছিলেন যাতে কেউ কোনো
ডেটা ফাইলে পার্সিং নির্দেশ লুকিয়ে রাখতে না পারে। কোনো ট্রেইলিং কমা নেই, কারণ কমা একটি বিভাজক
এবং শেষ উপাদানের পরে দেখা দিতে পারে না। কি ও স্ট্রিং ভ্যালু উভয়ের জন্য কেবল ডবল কোট
অনুমোদিত; JavaScript-এ আপনি যে সিঙ্গল কোট ও কোট ছাড়া কি ব্যবহার করতে পারেন তা বৈধ JSON নয়।
এবং কীওয়ার্ড true, false ও null কেস-সংবেদনশীল, তাই True
বা NULL ব্যর্থ হবে।
সংখ্যা-নির্ভুলতার ফাঁদ
JSON কোনো সংখ্যার আকার বা নির্ভুলতার ওপর কোনো সীমা আরোপ করে না, তবে বেশিরভাগ পার্সার — আপনার ব্রাউজারের
JSON.parse সহ — সংখ্যাগুলোকে 64-বিট IEEE 754 ফ্লোটিং-পয়েন্ট ভ্যালুতে পড়ে। এটি
ইন্টিজারকে নিরাপদে কেবল 253 − 1 পর্যন্ত
(9007199254740991, JavaScript-এ Number.MAX_SAFE_INTEGER হিসেবে উপলব্ধ)
উপস্থাপন করে। এর চেয়ে বড় কোনো 64-বিট ডেটাবেস ID বা খুব দীর্ঘ সংখ্যাসূচক টোকেন পার্স হওয়ার সময় নীরবে
গোল (rounded) হয়ে যাবে। মানক সমাধান হলো এমন ভ্যালুগুলোকে স্ট্রিং হিসেবে পাঠানো
এবং কেবল সেখানেই রূপান্তর করা যেখানে বিগ-ইন্টিজার টাইপ উপলব্ধ। এটি একটি সূক্ষ্ম বাগ যা সম্পর্কে কোনো
ফরম্যাটার আপনাকে সতর্ক করতে পারে না, কারণ গোলাইটি পার্সারের ভেতরেই ঘটে ভ্যালুটি পৃষ্ঠায় পৌঁছানোর আগে।
JSON বনাম XML বনাম YAML
JSON-এর আগে, XML ছিল প্রধান আদান-প্রদান ফরম্যাট। XML শক্তিশালী — এটি অ্যাট্রিবিউট, নেমস্পেস, স্কিমা (XSD) ও ভ্যালিডেশন সমর্থন করে — তবে এটি বাচাল: প্রতিটি উপাদানের একটি খোলা ও বন্ধ ট্যাগ প্রয়োজন, যা পেলোডের আকার ও পার্সিং খরচ বাড়িয়ে দেয়। JSON একই ডেটা অনেক কম টেক্সটে প্রকাশ করে এবং বেশিরভাগ ভাষার নেটিভ গঠনের (অবজেক্ট, অ্যারে, ম্যাপ, লিস্ট) ওপর সরাসরি ম্যাপ হয়, এ কারণেই REST API বিপুল সংখ্যাগরিষ্ঠতায় এতে চলে এসেছে।
YAML হলো JSON-এর একটি নিকট-অধিসমষ্টি (near-superset) যা কমেন্ট, অ্যাঙ্কর ও ফাঁকা-জায়গা-ভিত্তিক লেআউট যোগ করে, যা এটিকে মানুষ-দ্বারা-সম্পাদিত কনফিগারেশন যেমন CI পাইপলাইন ও Kubernetes ম্যানিফেস্টের জন্য জনপ্রিয় করে তোলে। এর ট্রেড-অফ হলো YAML-এর ইনডেন্টেশন-সংবেদনশীলতা তাকে হাতে সহজে ভেঙে ফেলার উপযোগী করে, যেখানে JSON-এর স্পষ্ট ব্র্যাকেট দ্ব্যর্থহীন। একটি উপযোগী নিয়ম: মেশিনের জন্য JSON, মানুষের জন্য YAML, সমৃদ্ধ মার্কআপ ও মিশ্র বিষয়বস্তুর নথির জন্য XML।
শিথিল আত্মীয়: JSON5, JSONC ও NDJSON
বেশ কিছু এক্সটেনশন নির্দিষ্ট কাজের জন্য JSON-এর নিয়ম শিথিল করে। JSONC ("JSON with
Comments") কেবল // ও /* */ কমেন্টের অনুমতি দেয় এবং এটিই Visual Studio Code তার
সেটিংস ফাইলের জন্য ব্যবহার করে। JSON5 আরও এগিয়ে গিয়ে সিঙ্গল কোট, কোট ছাড়া কি, ট্রেইলিং
কমা ও হেক্সাডেসিমাল সংখ্যার অনুমতি দেয় যাতে হাতে-সম্পাদিত ফাইল আরও ক্ষমাশীল হয়।
NDJSON (JSON Lines নামেও পরিচিত) প্রতি লাইনে একটি স্বাধীন JSON অবজেক্ট সংরক্ষণ করে,
যা স্ট্রিমিং লগ ও বড় ডেটাসেটের জন্য আদর্শ কারণ একটি রিডার পুরো ফাইল লোড না করেই একবারে একটি রেকর্ড
প্রক্রিয়া করতে পারে। এদের কোনোটিই কঠোর JSON-এর সঙ্গে বিনিময়যোগ্য নয় — কোনো সার্ভার যদি RFC 8259 JSON-এর
প্রত্যাশা করে, তবে কমেন্ট ও ট্রেইলিং কমা প্রত্যাখ্যাত হবে, যা কোনো "ঠিক দেখতে" পেলোডের পার্স না হওয়ার
সবচেয়ে সাধারণ একক কারণ।
JSON আপনি কোথায় পাবেন
একবার খেয়াল করতে শুরু করলে JSON সর্বত্র। এটি বেশিরভাগ REST ও GraphQL API-এর বডি ফরম্যাট;
অগণিত টুলের কনফিগারেশন ভাষা (package.json, tsconfig.json,
composer.json); MongoDB-এর মতো NoSQL ডেটাবেসের নেটিভ নথি ফরম্যাট; এবং প্রতিটি
JSON Web Token-এর পেলোড। বিশেষ উপভাষা এটিকে নতুন ক্ষেত্রে বিস্তৃত করে:
GeoJSON মানচিত্র ও ভৌগোলিক আকৃতি এনকোড করে, JSON-LD সেই কাঠামোবদ্ধ-ডেটা
স্নিপেটগুলোকে শক্তি দেয় যা সার্চ ইঞ্জিন পড়ে, এবং JSON Schema অন্য JSON নথির আকৃতি বর্ণনা ও
ভ্যালিডেট করে। JSON ভালোভাবে জানা আধুনিক সফটওয়্যারের সবচেয়ে উচ্চ-সুবিধার দক্ষতাগুলোর একটি, কারণ একই ফরম্যাট
এত জায়গায় বারবার ফিরে আসে।
প্রিটি-প্রিন্ট নাকি মিনিফাই? এটি পাঠকের উপর নির্ভর করে
বিউটিফাই করা JSON, ইনডেন্টেশন ও লাইন-ব্রেকসহ, একজন পাঠকের জন্য: মানুষ। মিনিফাই করা JSON, প্রতিটি ঐচ্ছিক স্পেস সরিয়ে, একজন ভিন্ন পাঠকের জন্য: নেটওয়ার্ক। যে ডেটা আপনি ওয়্যারে পাঠাতে যাচ্ছেন তা মিনিফাই করুন — তবে মনে রাখবেন HTTP রেসপন্স প্রায় সবসময় gzip- বা Brotli-সংকুচিত হয়, এবং সংকোচন ইতিমধ্যেই পুনরাবৃত্ত ফাঁকা জায়গা অত্যন্ত দক্ষতার সঙ্গে গুটিয়ে দেয়, তাই সংকোচনের পরে বাস্তব আকার-পার্থক্য সাধারণত সামান্য। মিনিফাই করার বড় সুবিধা কেবল পার্স করার জন্য কম বাইট। যা কিছু আপনি পড়ছেন, ডিবাগ করছেন, ভার্সন কন্ট্রোলে কমিট করছেন বা কোনো বাগ রিপোর্টে পেস্ট করছেন, তা আগে বিউটিফাই করুন: একটি পরিষ্কার, ইনডেন্টেড গঠন কোনো বাদ পড়া ব্র্যাকেট বা ভুল জায়গায় রাখা ভ্যালু এক নজরে স্পষ্ট করে দেয়।
JSON ও নিরাপত্তা নিয়ে একটি মন্তব্য
JSON পার্স করা নিরাপদ; তা মূল্যায়ন (evaluate) করা নয়। শুরুর দিকে কিছু ডেভেলপার
JSON-কে JavaScript-এর eval()-এ পাস করে পার্স করতেন, যা টেক্সটে লুকানো যেকোনো কোড
নির্বাহ করত — একটি গুরুতর দুর্বলতা। সবসময় JSON.parse-এর (যা এই টুল ব্যবহার করে) মতো একটি
আসল পার্সার ব্যবহার করুন এবং কখনো eval নয়। একটি সূক্ষ্মতা জানার মতো: অবিশ্বস্ত JSON-এ
__proto__ নামের একটি কি, কিছু লাইব্রেরিতে, "প্রোটোটাইপ-পলিউশন" (prototype-pollution) আক্রমণের জন্য
ব্যবহৃত হয়েছে। ভালোভাবে রক্ষণাবেক্ষণ করা পার্সার এখন এর বিরুদ্ধে রক্ষা করে, তবে এটি অবিশ্বস্ত JSON-কে সংবেদনশীল
অবজেক্ট-মার্জিং কোডে সরাসরি না দেওয়ার একটি ভালো কারণ।
JSON-এ কোনো ডেট টাইপ নেই
একটি সাধারণ বিস্ময় হলো JSON-এ তারিখ, সময় বা বাইনারি ডেটার জন্য কোনো নেটিভ উপস্থাপনা নেই — কেবল উপরে বলা ছয়
টাইপ। বিপুল সংখ্যাগরিষ্ঠ প্রথা অনুসারে, তারিখ ISO 8601 স্ট্রিং যেমন
"2026-06-30T14:00:00Z" হিসেবে বহন করা হয়, এবং বাইনারি ব্লব Base64-এনকোড করা
স্ট্রিং হিসেবে। আপনি যখন কোনো JavaScript Date JSON.stringify দিয়ে সিরিয়ালাইজ করেন
তখন আপনি স্বয়ংক্রিয়ভাবে একটি ISO 8601 স্ট্রিং পান, তবে তা আবার পার্স করলে আপনি একটি স্ট্রিং পান, কোনো
Date নয় — তা আপনাকে নিজে রূপান্তর করতে হয়। প্রতিটি টাইমস্ট্যাম্পকে UTC (শেষের Z)
ধরা এবং কেবল প্রদর্শনের জন্য স্থানীয় সময়ে বদলানো টাইমজোন বাগ এড়ানোর সবচেয়ে নির্ভরযোগ্য উপায়।
ডুপ্লিকেট কি ও কি-অর্ডার
আরও দুটি বিষয় মানুষকে বিভ্রান্ত করে। প্রথমত, RFC 8259 বলে যে কোনো অবজেক্টের ভেতরের নাম অনন্য হওয়া উচিত তবে ডুপ্লিকেট নিষিদ্ধ করে না, এবং এটি এমন পার্সারের আচরণকে অনির্ধারিত রেখে দেয় যা কোনো পুনরাবৃত্ত কি-এর মুখোমুখি হয়। বাস্তবে বেশিরভাগ পার্সার, ব্রাউজারেরটি সহ, শেষ ঘটনা রাখে — তবে আপনার তার ওপর কখনো নির্ভর করা উচিত নয়, এবং ডুপ্লিকেট কি আন্তঃপরিচালনযোগ্যতা বাগের একটি ক্লাসিক উৎস। দ্বিতীয়ত, যদিও একটি JSON অবজেক্ট আনুষ্ঠানিকভাবে একটি অসজ্জিত সংগ্রহ, প্রতিটি মূলধারার পার্সার কি-এর প্রবেশ-ক্রম সংরক্ষণ করে, এবং এই ফরম্যাটার বিউটিফাই বা মিনিফাই করার সময় আপনার কি-গুলো ঠিক সেই ক্রমে রাখে যে ক্রমে আপনি লিখেছেন। আপনার অ্যাপ্লিকেশন যদি সত্যিই কোনো নির্দিষ্ট ক্রমের ওপর নির্ভর করে, তবে তা স্পষ্টভাবে এনকোড করুন — উদাহরণস্বরূপ জোড়ার একটি অ্যারে হিসেবে — অবজেক্ট কি-অর্ডারের ওপর ভরসা না করে।
JSON-এ নেভিগেট করা: JSONPath ও JSON Pointer
নথি যত বড় হয়, আপনার তাদের ভেতরে গভীরে কোনো ভ্যালুর ঠিকানা দেওয়ার উপায় প্রয়োজন। দুটি ছোট মানক
ঠিক তা-ই করে। JSON Pointer (RFC 6901) একটি স্ল্যাশ-বিভক্ত পথ যেমন
/users/0/email ব্যবহার করে একটি সঠিক অবস্থানের দিকে নির্দেশ করতে — এটিই JSON Patch ও
JSON Schema অভ্যন্তরীণভাবে কোনো নোড উল্লেখ করতে ব্যবহার করে। JSONPath একটি আরও
অভিব্যক্তিপূর্ণ, ক্যোয়ারি-সদৃশ সিনট্যাক্স (XML-এর জন্য XPath দ্বারা অনুপ্রাণিত) যা একসাথে একাধিক নোড বেছে
নিতে, শর্ত দিয়ে ফিল্টার করতে ও ওয়াইল্ডকার্ড ব্যবহার করতে পারে — উদাহরণস্বরূপ প্রতিটি ব্যবহারকারীর ইমেইল
বের করতে $.users[*].email। Pointer উত্তর দেয় "এই একটি জায়গা"; JSONPath উত্তর দেয় "যা কিছু
মেলে"। এরা যে বিদ্যমান তা জানা কোনো বড় বিউটিফাই করা নথিতে হাতে খোঁজাখুঁজি অনেক বাঁচায়।
বড় JSON নিয়ে কাজ করার টিপস
ব্রাউজার-ভিত্তিক টুল, এই টুল সহ, কয়েক-মেগাবাইট ফাইল অনায়াসে সামলায় কারণ কাজটি আপনার মেশিনে
স্থানীয়ভাবে হয়। নথি সত্যিই বড় হয়ে গেলে কিছু অভ্যাস সাহায্য করে। পড়ার আগে
বিউটিফাই করুন যাতে গঠন দৃশ্যমান হয়, তবে পরিবহনের জন্য একটি মিনিফাই করা কপি রাখুন। যেসব ফাইল একবারে
মেমরিতে রাখার জন্য বড্ড বড়, তাদের জন্য NDJSON (প্রতি লাইনে একটি অবজেক্ট) অগ্রাধিকার দিন
এবং তা লাইন-বাই-লাইন প্রক্রিয়া করুন, বা এমন একটি স্ট্রিমিং পার্সার ব্যবহার করুন যা পুরো
ট্রি তৈরির বদলে পড়তে পড়তে ভ্যালু নির্গত করে। এবং কোনো API যখন একটি বড় সংগ্রহ ফেরত দেয়, তখন সবকিছু একসাথে
চাওয়ার বদলে পেজিনেশন — একটি next কার্সার বা পেজ প্যারামিটার — খুঁজুন; ভালো
ডিজাইন করা API কখনো প্রত্যাশা করে না যে আপনি একটি রেসপন্সেই দশ লক্ষ রেকর্ড ডাউনলোড করবেন।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
- আমার JSON কি কোনো সার্ভারে আপলোড হয়?
- না। ফরম্যাটিং, ভ্যালিডেশন ও মিনিফিকেশন — সবকিছু আপনার ব্রাউজারে JavaScript দিয়ে চলে। আপনার ডেটা কখনো আপনার ডিভাইস থেকে বাইরে যায় না, যা টুলটিকে দ্রুত ও সংবেদনশীল পেলোডের জন্য নিরাপদ করে তোলে।
- আমার JSON অবৈধ কেন?
- সবচেয়ে সাধারণ কারণগুলো হলো — শেষ আইটেমের পরে ট্রেইলিং কমা, ডবল কোটের বদলে সিঙ্গল কোট, কোট ছাড়া অবজেক্ট কি, কমেন্ট (JSON-এ কোনোটিই নেই), বা কোনো বাদ পড়া ব্র্যাকেট/ব্রেস। এই টুলটি আপনাকে ঠিক সেই লাইন ও কলাম দেখায় যেখানে পার্সিং ব্যর্থ হয়েছে।
- ফরম্যাটিং, ভ্যালিডেশন ও মিনিফিকেশনের মধ্যে পার্থক্য কী?
- ভ্যালিডেট করা যাচাই করে টেক্সটটি সুগঠিত (well-formed) JSON কিনা। ফরম্যাট (বিউটিফাই) করা বৈধ JSON-কে আবার ইনডেন্ট করে যাতে তা পড়ার উপযোগী হয়। মিনিফাই করা সমস্ত ফাঁকা জায়গা সরিয়ে দেয় যাতে পেলোড পরিবহনের জন্য যতটা সম্ভব ছোট হয়। এই টুলটি তিনটি কাজই একটি বক্স থেকে করে।
- ফরম্যাটিং কি আমার ডেটা বদলে দেয়?
- না। বিউটিফাই ও মিনিফাই শুধু ফাঁকা জায়গা বদলায় — কি, ভ্যালু, টাইপ ও গঠন একই থাকে। অবজেক্ট কি-অর্ডার যেমন লেখা হয়েছিল ঠিক তেমনই রাখা হয়।
- এটি কত বড় ফাইল সামলাতে পারে?
- যেহেতু এটি আপনার ব্রাউজারে চলে, এটি সাধারণ API রেসপন্স ও কনফিগ ফাইল (কয়েক MB) অনায়াসে সামলায়। অত্যন্ত বড় ফাইল কেবল আপনার ডিভাইসের মেমরি দিয়ে সীমিত হয়, কোনো আপলোড সীমা দিয়ে নয়।