DEV Community: WangLiwen

Everything You Always Wanted to Know About LocalStorage in JavaScript

WangLiwen — Mon, 20 Oct 2025 10:42:45 +0000

Dive into the world of LocalStorage, an essential part of JavaScript for managing data across browser sessions. This article covers what LocalStorage is, how it works, its limitations, and best practices for using it effectively.

In the realm of web development, storing data locally on user's browsers can be a powerful tool for enhancing the functionality of websites. One such powerful feature provided by JavaScript is LocalStorage. This article will cover everything you need to know about LocalStorage, from its basic concepts to advanced usage scenarios.

What is LocalStorage?

Local Storage is a web storage API that allows developers to store key-value pairs on the client-side (i.e., within the user's browser) instead of the server-side. Unlike cookies, which have limited storage space (typically 4KB per domain), LocalStorage offers much more storage capacity (up to 5MB per domain). This makes it ideal for saving larger amounts of data or storing sensitive information.

How Does LocalStorage Work?

Local Storage operates similarly to cookies, but with a few crucial differences. First, LocalStorage does not expire automatically; you must explicitly remove data from the storage area. Second, it is not sent to the server with each request, unlike cookies, which means it can't be tampered with easily. Third, LocalStorage is not accessible via the URL, making it harder for users to access stored data through their browser history or bookmarks.

Here’s a simple example of how to use LocalStorage:

// Storing data
localStorage.setItem('username', 'JohnDoe');

// Retrieving data
let username = localStorage.getItem('username');
console.log(username); // Outputs: JohnDoe

// Removing data
localStorage.removeItem('username');

// Clearing all data
localStorage.clear();

Limitations of LocalStorage

While LocalStorage is incredibly useful, it has some limitations that developers should be aware of. First, since data is stored locally, it may not be available when users switch devices or clear their cache. Second, because of the lack of encryption, sensitive data should be handled carefully. Finally, LocalStorage is not suitable for storing large amounts of data due to its size limits.

Best Practices for Using LocalStorage

To make the most out of LocalStorage, here are some best practices:

Use LocalStorage judiciously, especially for sensitive data.
Consider using cookies as a fallback option if LocalStorage is not available.
Regularly clear unused data to keep your storage efficient.
Encrypt data if security is a concern.
For very large datasets, consider using databases like IndexedDB or WebSQL.

Conclusion

LocalStorage is a versatile tool in the JavaScript developer's arsenal, providing a way to persistently store data without relying on server-side solutions. By understanding how it works and adhering to best practices, developers can leverage this feature to enhance user experiences and build robust applications. Whether you're tracking user preferences, maintaining session states, or caching frequently accessed data, LocalStorage is a powerful addition to any JavaScript developer's toolkit.

FAQs

How long does LocalStorage data persist?
Data persists until it is manually removed or the browser is cleared.

Can I store objects in LocalStorage?
Yes, you can store objects. However, they are serialized and deserialized.

Is LocalStorage secure?
No, LocalStorage is not encrypted, so sensitive data should be handled with care.

What happens if I try to access LocalStorage data outside of a browser environment?
It won’t work as intended because LocalStorage is tied to the browser context.

By mastering LocalStorage, developers can unlock new possibilities for building interactive and engaging web applications.

from: https://www.js-obfuscator.com/article/54322378.html

Obfuscate JS status

WangLiwen — Mon, 14 Jul 2025 03:38:48 +0000

Use js-obfuscator to obfuscate JS

javascript obfuscator,plateform lock

WangLiwen — Thu, 06 Mar 2025 09:11:33 +0000

javascript obfuscator

WangLiwen — Tue, 18 Feb 2025 11:00:19 +0000

javascript obfuscator

Some JavaScript Obfuscator Tools

WangLiwen — Mon, 23 Dec 2024 03:49:18 +0000

https://obfuscator.io/

JScrambler

https://jscrambler.com/

Stunnix

http://stunnix.com/

JS-Obfuscator

https://www.js-obfuscator.com/

JavaScript Obfuscator

https://www.javascriptobfuscator.com/

Free Online JavaScript Obfuscator

https://js-obfuscator.github.io/

JSDefender

https://www.preemptive.com/

JavaScript Anti Eval Debugging

WangLiwen — Fri, 29 Nov 2024 01:47:02 +0000

The proper use of eval is to execute a string of JavaScript code. However, it is also frequently used by code analyzers for debugging and analysis purposes: running certain functions with eval to get the return values and understand the execution results of the code.
How to implement anti-eval debugging and prevent code from being executed by eval? We can throw an error within a function and catch its stack trace, then check if the call stack contains eval. This way, we can identify whether the function was called through eval and take appropriate actions accordingly.

Example Code:


function checkIfEvalled() {
    try {
        throw new Error();
    } catch (e) {
        console.log(e.stack);
        if (e.stack.includes('eval')) {
            console.log("This function might have been called by eval.");
        } else {
            console.log("This function was not called by eval.");
        }
    }
}

// Normal call
checkIfEvalled();

// Call using eval
eval('checkIfEvalled();');

In actual application, to avoid the anti-eval logic being easily seen, one would not use console.log for notifications; instead, they could return an incorrect value or take other measures. Additionally, it's recommended to obfuscate and encrypt the code, such as using JS-Obfuscator for JavaScript code obfuscation.

JavaScript Base-32 Encryption

WangLiwen — Sat, 16 Nov 2024 09:25:17 +0000

In JavaScript programming, eval is often used to protect privacy, encrypt code execution, and run scripts that one does not want others to know about, such as common practices like eval encryption, U encryption, JJEncode encryption, all of which utilize eval for code execution.

However, the string "eval" itself is a very obvious characteristic, making it too easy to search for, and then replace with console.log, alert, thereby achieving reverse engineering and obtaining the content executed by eval.

Is there a way to also hide eval so that it's not so easily discovered? Of course, the following introduces one method: Base-32 Encryption.

The principle is as follows: eval is a member function of window in browsers; in the Node.js environment, it is a member function of global. Therefore, eval can also be written as:
window.eval, global.eval, or window["eval"], global["eval"].

This means that eval has been transformed into a string form. Since it is a string, it becomes easier to encrypt. For example, the "eval" string can take on another form:
(14).toString(32)+(31).toString(32)+(10).toString(32)+(21).toString(32)

Or, to avoid having a uniform feature after encryption, the value passed to toString can also be altered, such as changing 14 to 10+1+3:
window[(10+1+3).toString(32)+(20+1+10).toString(32)+(10).toString(32)+(21).toString(32)]

This uses the toString(base) method to convert a number to its string representation in the specified base. In the above example code, the base is 32, meaning numbers will be converted to strings in base 32.

(14).toString(32): The number 14 is converted to base 32, which is "e". (31).toString(32): The number 31 is converted to base 32, which is "v". (10).toString(32): The number 10 is converted to base 32, which is "a". (21).toString(32): The number 21 is converted to base 32, which is "l".

When concatenated with plus signs, they form the string "eval".

Further Base-32 character correspondence:
a: (10).toString(32) -> "a"
b: (11).toString(32) -> "b"
c: (12).toString(32) -> "c"
d: (13).toString(32) -> "d"
e: (14).toString(32) -> "e"
f: (15).toString(32) -> "f"
g: (16).toString(32) -> "g"
h: (17).toString(32) -> "h"
i: (18).toString(32) -> "i"
j: (19).toString(32) -> "j"
k: (20).toString(32) -> "k"
l: (21).toString(32) -> "l"
m: (22).toString(32) -> "m"
n: (23).toString(32) -> "n"
o: (24).toString(32) -> "o"
p: (25).toString(32) -> "p"
q: (26).toString(32) -> "q"
r: (27).toString(32) -> "r"
s: (28).toString(32) -> "s"
t: (29).toString(32) -> "t"
u: (30).toString(32) -> "u"
v: (31).toString(32) -> "v"

Of course, besides this, other algorithms can also be used, for example, in browsers, the base64 string “ZXZhbA==” can be decoded using atob to get “eval”: Expanding on this, this method can be used not only to hide eval but also to conceal other methods. For instance, consider this line of code suitable for browser execution:
window[(10).toString(32)+(21).toString(32)+(14).toString(32)+(27).toString(32)+atob("dA==")]("moc.rotacsufbo-sj".split("").reverse().join(""));

What would this output? Try it out yourself.

Have you ever seen variables defined like this in JavaScript?

WangLiwen — Wed, 09 Oct 2024 23:57:57 +0000

Typically, in JS, variables are defined using var, let, or const.

For example: var abc = 1;

But what if you don't want others to see that you've defined a variable abc? How should you do it?

You can write it like this: this["abc"] = 1;

This also defines a variable abc.

Huh? Can you write it like this? Yes, you can! Don't believe it? Just run a test to find out.

But this still reveals the abc string and shows that the assigned value is the number 1. Is there a way to make it even more obscure?

Yes, you can also use JS-Obfuscator.com to obfuscate this line of code.

After obfuscation, this["abc"] = 1; will become:

this["\u0061\u0062\u0063\u0064"] = 0x3ba17 ^ 0x3ba16;

At this point, if you use console.log(abc) or alert(abc), you will see that the value 1 of the variable abc is output.

However, at a glance, neither the variable abc nor the number 1 is immediately visible in this line of code.

Isn't that interesting?

Have you learned this JS programming trick?

Do we really need to obfuscate JS code?

WangLiwen — Thu, 19 Sep 2024 02:49:48 +0000

Do we really need to obfuscate JS code?

Regarding whether or not to obfuscate and encrypt web JS code, some argue, "There's no security in the frontend, obfuscation is useless, and even if obfuscated, others can eventually reverse engineer it with time and effort, so JS code doesn't need protection." Is this viewpoint correct?

Theoretically speaking, this notion appears to be somewhat valid: obfuscated and encrypted JS code, given enough time and dedication, can indeed be analyzed to a considerable extent. Similar to how an exe file can be disassembled and its logic gradually analyzed using tools like IDA. However, the crucial difference lies in the "time cost" and the required technical expertise.

For instance, a JS source code feature might take merely three minutes to comprehend if left in plaintext, but could take hours, days, months, or even longer if obfuscated and encrypted. This significantly discourages many individuals with average technical skills, especially when the time invested in reverse engineering exceeds the time it would take to develop the feature from scratch.

Moreover, capable developers might not even consider reverse-engineering or stealing others' source code. Such activities could even be illegal (especially for commercial code), which intelligent individuals would avoid.

Hence, obfuscating and encrypting JS code not only enhances security but also demonstrates a heightened sense of security awareness, which is undoubtedly preferable to publishing code transparently.

Based on the above, personally, I believe obfuscating and encrypting JS code before publication is an excellent choice. I find it puzzling why some would oppose this practice.

Of course, if the code is entirely unimportant or inconsequential, the effort of obfuscation and encryption might not be necessary, given that it does take a few minutes to perform. (Note: Open-source products also don't require this...)

Additionally, some may wonder if obfuscated JS code can still function correctly and whether it might break. These concerns are largely unfounded. JS obfuscation tools are mature and reliable, with popular offerings like JShaman, JScrambler, JsJiaMi.online, and JS-Obfuscator having been around for years, providing stable and trustworthy services.

In conclusion, our company has a clear policy that all JS code must be obfuscated and encrypted before publication. This is a matter of security awareness and prevention. Releasing source code unchecked is essentially inviting others to freely copy and use it.

Is JS obfuscation the same as JS encryption?

WangLiwen — Mon, 01 Jul 2024 00:57:05 +0000

Is JS obfuscation the same as JS encryption?

In most cases, JS obfuscation and JS encryption refer to the same thing.

Conventionally, non-English-speaking countries refer to it as JS encryption, while English-speaking countries call it obfuscation. They are actually the same. Both refer to protecting JS code, such as making variable names meaningless, encrypting strings, scrambling execution flows, and so on. The purpose is to make JS code unreadable and difficult to understand, thus preventing the code written by oneself from being used or analyzed by others.

JS obfuscation and JS encryption have become a mature industry, with many popular tools, often in the form of SaaS online websites. For example, js-obfuscator, jshaman, jsjiami.online, are all professional JS obfuscation and encryption tools.

However, in JS programming, there is another type of encryption, referring to encryption algorithms, such as MD5 encryption and Base64 encoding. But they are generally referred to directly as encryption algorithms, rather than JS obfuscation or JS encryption.

How to Obfuscate JavaScript?

WangLiwen — Thu, 30 May 2024 02:28:25 +0000

How to Obfuscate JavaScript?

JavaScript obfuscation is a technique used to make code difficult to read and understand while still maintaining its functionality. This is often done to protect intellectual property, hide implementation details, or simply to deter casual reverse engineering attempts. However, it's important to note that obfuscation does not guarantee security and should not be relied upon as a primary means of defense.

Why Obfuscate JavaScript?

Protection of IP: Companies often want to protect their algorithms and logic from being stolen or copied.
Hiding Implementation Details: Developers may want to hide certain implementation details to make it harder for others to understand or replicate their work.
Deterrence: Obfuscated code can deter casual reverse engineering attempts, making it less appealing for hackers or competitors.

Techniques for Obfuscating JavaScript

Variable Renaming: Renaming variables and functions to random or meaningless names can make code harder to read. Tools like UglifyJS and Terser can automatically rename variables during minification.
String Encoding: Encoding strings as hexadecimal, base64, or other formats can make them unreadable in the source code. However, this can be easily decoded by an attacker.
Control Flow Flattening: This technique transforms the control flow of the program to make it harder to analyze. Tools like JavaScript Obfuscator can achieve this.
Dead Code Insertion: Inserting code that doesn't affect the program's behavior but makes it harder to understand. This can include unused variables, functions, or loops.
Code Splitting and Evaluation: Splitting code into multiple parts and evaluating them dynamically can make it harder to analyze statically.
Encryption: Encrypting parts of the code or data can add another layer of obscurity, but it can also increase the complexity of the code.

Best Practices for Obfuscation

Use Established Tools: Tools like JScrambler, JS-Obfuscator, JShaman,etc... They have been widely used and tested. They provide reliable obfuscation while minimizing the chances of introducing errors.
Test Thoroughly: After obfuscating your code, thoroughly test it to ensure that it still functions as expected. Obfuscation tools can sometimes introduce subtle bugs.
Don't Rely Solely on Obfuscation: Remember that obfuscation is not a substitute for secure coding practices. Use it as an additional layer of defense but not as your primary means of security.
Be Aware of the Drawbacks: Obfuscated code can be harder to debug and maintain. Ensure that your team is aware of this and has the necessary tools and skills to work with obfuscated code.

Conclusion

JavaScript obfuscation can be a useful technique to protect your code and deter casual reverse engineering attempts. However, it should be used as an additional layer of defense and not relied upon as a primary means of security. Use established tools, thoroughly test your code, and be aware of the drawbacks of obfuscation to ensure that you're getting the most out of this technique.

JavaScript Magic Tricks: Invalid breakpoint

WangLiwen — Mon, 20 May 2024 00:37:30 +0000

Under normal conditions, JavaScript code can be breakpointed in a runtime environment, for example:

<html>
<script>
var array = ["JShaman","javascript","Obfuscator"];
for(i=0 ;i< array.length; i++){
    console.log(array[i]);
}
</script>
</html>

But do you know that there are some techniques in JS programming that can effectively make breakpoints useless? For example, by rewriting the code above as:

<html>
<script>
var array = ["JShaman","javascript","Obfuscator"];
array.forEach(console.log);
</script>
</html>

If you set a breakpoint and run it at this time, you will find that: the breakpoint will only occur inside forEach, but console.log will not be interrupted:

This method also applies in Node.JS and Visual Studio Code environments, as shown in the following two figures:

Another example:

<html>
<script>
    window.onclick = function() {
        document.bgColor = "#ccc";
    }
</script>
</html>

This code snippet is used to set the background color of a webpage with document.bgColor = "#ccc";. This line of code can be set as a breakpoint. If you do not want it to be interrupted by a breakpoint, you can modify the code to the following format:

<html>
<script>
window.onclick = Object.getOwnPropertyDescriptor(Document.prototype, "bgColor").set.bind(document, "#ccc");
</script>
</html>

Object.getOwnPropertyDescriptor() is a method added to the Object object in the ES6 specification, allowing the retrieval of a descriptor for a specified property of an object. The method takes two parameters: the first is the object that contains the property, and the second is the name of the property. It returns an object. In the code mentioned above, it is used to retrieve the descriptor of the bgColor property in the document and bind it to an onclick event. When the onclick event is triggered, it will set the background color, but the set.bind(document, "#ccc") operation will not be paused by a breakpoint, and breakpoints are ineffective on it.

Another example:

<html>
<script>
    var obj = {
        name : "tom"
    };
    obj.name = "ais";
    console.log(obj);
</script>
</html>

If you do not want the breakpoint to be set for the statement obj.name = "ais" that assigns a value to name, you can make the following adjustments:
Change to:

Reflect.apply(Reflect.set, null, [obj, “name”, “ais”]);

Reflect is a new API provided in ES6 for object manipulation, which offers methods to intercept JavaScript operations:
Reflect.apply(target, thisArg, args), the apply method calls a function with a given this value and an array of arguments. The code snippet above is equivalent to obj.name = "ais".
However, breakpoints can still be set here, and the bind method can be used further:
Reflect.apply.bind(null, Reflect.set, null, [obj, "name", "aix"]);

Finally:


<html>
<script>
    var obj = {
        name : "tom"
    };
    window.onclick= Reflect.apply.bind(null, Reflect.set, null, [obj, "name", "aix"]);
    console.log(obj);
</script>
</html>

At this point, a breakpoint can be set on the line with Reflect.apply.bind, but the execution will not pause or interrupt when window.onclick is triggered.

This method can be used to protect the code that is most afraid of debugging in certain situations.
Furthermore, if the code modified using this method is then obfuscated and encrypted, it may even be impossible to locate the location of the breakpoint. As shown in the following image, encrypting the preceding code with JS-Obfuscator will result in the following form

<html>
<script>
    function _0x4bfaa1(_0x4f04df,_0x46ffc7,_0x157578,_0x297168,_0x5a371e){return _0x497c(_0x46ffc7- -0x1f8,_0x297168);}function _0x40ba00(_0x265865,_0x51dc79,_0x267b51,_0x3b1913,_0x2ac5f5){return _0x497c(_0x267b51-0xcc,_0x3b1913);}(function(_0x15f460,_0x18170b){function _0x3440c3(_0x3f98c7,_0x197e80,_0x48af91,_0x537374,_0x4fa527){return _0x497c(_0x48af91-0x2d6,_0x197e80);}var _0x40fdd0=_0x15f460();function _0xc97ade(_0x1c2d14,_0x273c74,_0x2d7a20,_0x2347d2,_0x4fe5df){return _0x497c(_0x2d7a20-0x2b5,_0x4fe5df);}function _0x551607(_0x3e01fd,_0x110b1d,_0x2eeec9,_0x17b1d5,_0x145826){return _0x497c(_0x3e01fd- -0x22d,_0x110b1d);}function _0xa1f138(_0x387226,_0x1f0366,_0x1b6130,_0xb0bfb3,_0x2b254a){return _0x497c(_0x2b254a- -0x2b1,_0x1f0366);}function _0x486f8e(_0x173deb,_0x592ea4,_0xb13e25,_0xb03b2e,_0x14e4f9){return _0x497c(_0xb13e25- -0x3bb,_0xb03b2e);}while(!![]){try{var _0x2d2b91=parseInt(_0x551607(-0x22a,-0x227,-0x229,-0x22b,-0x221))/0x1+-parseInt(_0xc97ade(0x2be,0x2c4,0x2c6,0x2bf,0x2c4))/0x2*(-parseInt(_0xc97ade(0x2b9,0x2ad,0x2b5,0x2b9,0x2b0))/0x3)+parseInt(_0xa1f138(-0x2a4,-0x2ab,-0x2af,-0x2af,-0x2aa))/0x4+-parseInt(_0x3440c3(0x2e2,0x2e1,0x2e3,0x2e3,0x2e5))/0x5+parseInt(_0x3440c3(0x2d7,0x2d8,0x2e0,0x2da,0x2e6))/0x6+-parseInt(_0xc97ade(0x2bc,0x2bb,0x2ba,0x2b4,0x2b3))/0x7*(parseInt(_0xa1f138(-0x2ab,-0x2a7,-0x2a9,-0x2a3,-0x2a2))/0x8)+-parseInt(_0x3440c3(0x2de,0x2e1,0x2e4,0x2ec,0x2dd))/0x9*(-parseInt(_0x486f8e(-0x3be,-0x3b6,-0x3b7,-0x3be,-0x3b0))/0xa);if(_0x2d2b91===_0x18170b){break;}else{_0x40fdd0["\u0070\u0075\u0073\u0068"](_0x40fdd0["\u0073\u0068\u0069\u0066\u0074"]());}}catch(_0x45ceea){_0x40fdd0["\u0070\u0075\u0073\u0068"](_0x40fdd0["\u0073\u0068\u0069\u0066\u0074"]());}}})(_0x5a63,0x95c8c);function _0x5a63(){var _0x45b434=["\u0034\u0031\u0035\u0030\u0031\u0039\u0032\u0050\u0043\u0065\u0050\u0050\u0054","\u006c\u006f\u0067","dnib".split("").reverse().join(""),"\u0031\u0032\u0034\u0038\u0031\u0032\u0036\u0079\u0065\u0069\u004c\u0048\u0066","eman".split("").reverse().join(""),"\u0061\u0069\u0078","WrBRpq0878165".split("").reverse().join(""),"yxfsXT01521".split("").reverse().join(""),"\u0032\u0033\u0032\u0078\u0062\u004a\u0069\u0067\u0058","\u0061\u0070\u0070\u006c\u0079","GvgsnD41".split("").reverse().join(""),"LoNwch907911".split("").reverse().join(""),"mot".split("").reverse().join(""),"kcilcno".split("").reverse().join(""),"thpllB6243101".split("").reverse().join(""),"szBFSp023".split("").reverse().join(""),"pytQaz290402".split("").reverse().join(""),"tes".split("").reverse().join("")];_0x5a63=function(){return _0x45b434;};return _0x5a63();}var _0xc=0x4+0x1;var obj={"\u006e\u0061\u006d\u0065":_0x4bfaa1(-0x1f1,-0x1f7,-0x1f6,-0x1f8,-0x1f5)};_0xc=0x2+0x7;function _0x7b3856(_0x298c79,_0x37904f,_0x2e5981,_0x37e404,_0x363429){return _0x497c(_0x37e404-0x250,_0x363429);}function _0x497c(_0x2e43ba,_0x5a63b9){var _0x497cff=_0x5a63();_0x497c=function(_0x6145ca,_0x364243){_0x6145ca=_0x6145ca-0x0;var _0x46f7f9=_0x497cff[_0x6145ca];return _0x46f7f9;};return _0x497c(_0x2e43ba,_0x5a63b9);}window["\u006f\u006e\u0063\u006c\u0069\u0063\u006b"]=Reflect["\u0061\u0070\u0070\u006c\u0079"]["\u0062\u0069\u006e\u0064"](null,Reflect["\u0073\u0065\u0074"],null,[obj,_0x7b3856(0x25b,0x261,0x257,0x25b,0x25a),_0x7b3856(0x259,0x253,0x25c,0x25c,0x257)]);console["\u006c\u006f\u0067"](obj);
</script>
</html>