अपने कोड की सुरक्षा के कई कारण हैं: किसी को भी आपके काम को सीधे कॉपी/पेस्ट करने से रोकना (HTML5 गेम्स जैसे क्लाइंट-साइड प्रोजेक्ट्स के लिए यह ख़ास तौर पर महत्वपूर्ण है), कमेंट्स और खाली जगह हटाकर कोड को तेज़ी से लोड होने योग्य और समझने में कठिन बनाना, और ऐसे काम की सुरक्षा करना जिसका भुगतान अभी नहीं हुआ है, ताकि आप क्लाइंट को सोर्स कोड दिए बिना उसे दिखा सकें।

VM (वर्चुअल मशीन) ऑब्फ़स्केशन आपके JavaScript कोड को ऐसे कस्टम बाइटकोड में बदल देता है जो एक एम्बेडेड इंटरप्रेटर पर चलता है। स्टैंडर्ड ऑब्फ़स्केशन के विपरीत, जो अब भी पढ़ा जा सकने वाला JavaScript बनाता है, VM ऑब्फ़स्केशन आपके मूल कोड की संरचना को पूरी तरह छिपा देता है। स्टैटिक एनालिसिस टूल्स पूरी वर्चुअल मशीन को रिवर्स-इंजीनियर किए बिना लॉजिक समझ नहीं सकते। हमारी VM ऑब्फ़स्केशन गाइड में और जानें।

हाँ! हम विशिष्ट फ़ंक्शन्स या मेथड्स पर चुनकर VM ऑब्फ़स्केशन लागू करने का विकल्प देते हैं। बस अपने लक्षित फ़ंक्शन के ऊपर एक विशेष कमेंट (/* javascript-obfuscator:vm */) लगाएँ, और केवल वही फ़ंक्शन VM ऑब्फ़स्केटर से प्रोसेस होगा। यह तब आदर्श है जब आप केवल अपने सबसे संवेदनशील एल्गोरिदम को सुरक्षित करना चाहते हों और बाकी कोड को स्टैंडर्ड ऑब्फ़स्केशन के साथ या बिना बदलाव के रखना चाहते हों — इससे प्रदर्शन का ओवरहेड कम रहता है।

नहीं। API कुंजियाँ, सीक्रेट्स और क्रेडेंशियल्स कभी भी फ़्रंटएंड कोड में नहीं रखने चाहिए। ऑब्फ़स्केशन के सबसे ऊँचे स्तर के साथ भी, फ़्रंटएंड JavaScript में मौजूद कोई भी डेटा एक दृढ़ हमलावर द्वारा निकाला जा सकता है। ऑब्फ़स्केशन रिवर्स इंजीनियरिंग को कठिन बनाता है, पर यह एन्क्रिप्शन नहीं है और सीक्रेट्स की सुरक्षा के लिए इस पर भरोसा नहीं करना चाहिए। इसके बजाय सीक्रेट्स अपने बैकएंड सर्वर पर रखें, सर्वर साइड पर एनवायरनमेंट वेरिएबल्स का उपयोग करें, कुंजियाँ छिपाने के लिए API कॉल्स को अपने बैकएंड से प्रॉक्सी करें, या अपने सर्वर द्वारा जारी किए गए अल्पकालिक टोकन का उपयोग करें।

कोई भी ऑब्फ़स्केशन 100% अभेद्य नहीं है — JavaScript आख़िरकार उसी वातावरण में चलता है जिस पर हमलावर का नियंत्रण होता है — ब्राउज़र या Node.js — और वहाँ रनटाइम मेमोरी की जाँच हमेशा संभव है। कोई भी JavaScript ऑब्फ़स्केशन इसे पूरी तरह बंद नहीं कर सकता; वह इतना कर सकता है कि वहाँ तक पहुँचने की लागत बढ़ा दे। VM-ऑब्फ़स्केटेड कोड के लिए फ़िलहाल कोई ऑटोमेटेड ऑनलाइन डीऑब्फ़स्केटर सेवा मौजूद नहीं है — हर बार ऑब्फ़स्केशन कोड को एक अनोखी वर्चुअल मशीन वाले कस्टम बाइटकोड में कंपाइल करता है, जिससे सार्वभौमिक टूलिंग असंभव हो जाती है। स्टैंडर्ड ऑब्फ़स्केशन को तोड़ना कहीं आसान है: उसे अक्सर ऑटोमेटेड टूल्स और ब्यूटिफ़ायर से आंशिक रूप से पलटा जा सकता है। VM ऑब्फ़स्केशन के लिए पूरी वर्चुअल मशीन को रिवर्स-इंजीनियर करना, उसके बाइटकोड को डिक्रिप्ट और डिकोड करना, उसका इंस्ट्रक्शन सेट समझना और एक्ज़ीक्यूशन को ट्रेस करना पड़ता है — यह ऐसी प्रक्रिया है जिसमें हफ़्तों की समर्पित मेहनत लग सकती है। VM Self Defending के बिना, शक्तिशाली AI एजेंट (जैसे Claude Opus 4.7) बाइटकोड ट्रेस करके छोटे कोडबेस के लिए मूल कोड को मोटे तौर पर फिर से बना सकते हैं। VM Self Defending सक्रिय होने पर, बहुस्तरीय एंटी-LLM सुरक्षा — एंटी-हुकिंग, क्रॉस-रियल्म इंटीग्रिटी सत्यापन और बाइटकोड नेटिविटी जाँच — उन डायनामिक तकनीकों को बाधित कर देती है जिनसे कोई एजेंट बाइटकोड को समझने की कोशिश करता है: इंस्ट्रुमेंटेशन, हुकिंग और सैंडबॉक्स्ड एक्ज़ीक्यूशन। फ़ाइल को स्टैटिक रूप से पढ़ना अब भी संभव है, पर उससे केवल अपारदर्शी बाइटकोड ही सामने आता है, और उसे चलाने वाले रनटाइम को देखने की हर कोशिश इंटीग्रिटी जाँच में फँस जाती है। सिर्फ़ फ़ाइल के आधार पर ऑटोमेटेड AI डीऑब्फ़स्केशन अव्यावहारिक हो जाता है। अपने कोड को और मज़बूत करने के लिए: संवेदनशील फ़ंक्शन्स को IIFE में लपेटें ताकि नाम पूरी तरह बदल जाएँ, और बाइटकोड एन्क्रिप्शन जैसे हार्डनिंग विकल्प चालू करें। VM कोड को कैसे बदलता है, इस बारे में और जानें।

VM ऑब्फ़स्केशन एक जटिल तकनीक है, और कुछ एज केस पूरी तरह समर्थित नहीं हो सकते। यदि VM ऑब्फ़स्केशन के बाद आपका कोड टूट जाता है, तो vmTargetFunctionsMode: 'comment' की मदद से केवल चुनिंदा फ़ंक्शन्स को ऑब्फ़स्केट करके आप समस्या को सीमित कर सकते हैं। समस्याग्रस्त कोड की पहचान करने और समस्या की रिपोर्ट करने के चरण-दर-चरण निर्देशों के लिए हमारी ट्रबलशूटिंग गाइड देखें।

ऑब्फ़स्केटर डिबगिंग और रिवर्स-इंजीनियरिंग से बचाने के लिए नया कोड जोड़ता है। स्ट्रिंग्स हेक्साडेसिमल में बदल दी जाती हैं, और VM ऑब्फ़स्केशन के साथ आपके बाइटकोड के साथ एक पूरा वर्चुअल मशीन इंटरप्रेटर भी बंडल होता है। आकार की ज़्यादा चिंता न करें — ऑब्फ़स्केटेड कोड GZIP से बेहद अच्छी तरह कंप्रेस होता है, जिसे अधिकांश सर्वर डिफ़ॉल्ट रूप से चालू रखते हैं।

किसी भी ऑब्फ़स्केशन का प्रदर्शन पर कुछ न कुछ असर पड़ता है। स्टैंडर्ड ऑब्फ़स्केशन का ओवरहेड न्यूनतम होता है। VM ऑब्फ़स्केशन का असर कहीं ज़्यादा होता है और यह बहुत हद तक कोड पर निर्भर करता है - उदाहरण के लिए, ज़्यादा रिकर्सन वाला बाइटकोडेड कोड साफ़ तौर पर धीमा होगा। औसतन, low प्रीसेट लगभग 10 गुना असर डालता है, और Self Defending तथा Debug Protection वाला एंटी-LLM प्रीसेट लगभग 12 गुना धीमा होता है। आप विकल्पों को समायोजित करके या केवल संवेदनशील कोड हिस्सों पर चुनकर VM ऑब्फ़स्केशन लागू करके इस संतुलन को ठीक कर सकते हैं। ऑप्टिमाइज़ेशन सुझावों के लिए हमारी सर्वोत्तम प्रथाओं की गाइड देखें।

नहीं, यह अनुशंसित नहीं है और कुछ मामलों में इससे कोड टूट जाएगा (ख़ास तौर पर यदि आप self-defending चालू करते हैं)। हालाँकि आप ऑब्फ़स्केशन से पहले अपने कोड को मिनिफ़ायर से गुज़ार सकते हैं।

4.4MB से छोटी फ़ाइलों के लिए सोर्स पूरी तरह मेमोरी में प्रोसेस होता है और तुरंत ऑब्फ़स्केटेड आउटपुट के रूप में लौटा दिया जाता है। बड़ी फ़ाइलों के लिए (Team/Business प्लान) हम उन्हें अस्थायी रूप से सुरक्षित स्टोरेज में अपलोड करते हैं और ऑब्फ़स्केशन पूरा होते ही तुरंत हटा देते हैं। अतिरिक्त सुरक्षा के तौर पर, हर 5 मिनट में एक क्लीनअप जॉब चलता है जो 5 मिनट से पुरानी किसी भी फ़ाइल को हटा देता है। आपका कोड कभी संग्रहीत नहीं किया जाता।

नहीं, ऑब्फ़स्केटेड कोड को वापस आपके मूल कोड में बदलना असंभव है, इसलिए मूल कोड सुरक्षित रखें।

हाँ। Node.js वातावरण के लिए आउटपुट ऑप्टिमाइज़ करने हेतु आप ऑब्फ़स्केशन विकल्पों में टारगेट के रूप में "Node" चुन सकते हैं।

हम ES2015 (ES6) और ES2022+ सिंटैक्स, प्राइवेट क्लास फ़ील्ड्स, async/await, ऑप्शनल चेनिंग सहित सभी आधुनिक JavaScript फ़ीचर्स सपोर्ट करते हैं। TypeScript और JSX को ऑब्फ़स्केशन से पहले JavaScript में कंपाइल करना ज़रूरी है। किसी पेड प्लान के साथ आप HTML फ़ाइलें भी ऑब्फ़स्केट कर सकते हैं — जिन <script> टैग्स को सुरक्षित करना है उनमें data-javascript-obfuscator एट्रिब्यूट जोड़ें, और वे HTML संरचना बनाए रखते हुए अलग-अलग ऑब्फ़स्केट होंगे। ध्यान दें कि हर चिह्नित स्क्रिप्ट का कोड स्वयं-निहित होना चाहिए (अन्य स्क्रिप्ट्स का कोई संदर्भ न हो), और ES मॉड्यूल स्क्रिप्ट्स छोड़ दी जाती हैं।

ऑब्फ़स्केटेड आउटपुट — VM इंटरप्रेटर और Self Defending लेयर सहित — एवरग्रीन डेस्कटॉप ब्राउज़र्स और iOS 16+ (लगभग पिछले 3 साल) पर सक्रिय रूप से समर्थित और परीक्षित है। पुराने ब्राउज़र्स ES2015 मॉड्यूल सपोर्ट की न्यूनतम सीमा तक बेस्ट-एफ़र्ट आधार पर काम करते हैं; उससे नीचे कुछ भी, जिसमें Internet Explorer भी शामिल है, दायरे से बाहर है।

VM सुरक्षा के लिए हमारे प्राइसिंग प्लान देखें, या स्टैंडर्ड ऑब्फ़स्केशन के लिए मुफ़्त ऑनलाइन प्लेग्राउंड आज़माएँ। पूरी जानकारी के लिए शुरुआत करने की गाइड पढ़ें।

pricing.faq.usageMeasured.answer

pricing.faq.exceedLimit.answer

pricing.faq.upgradeDowngrade.answer

pricing.faq.cancel.answer

pricing.faq.paymentMethods.answer