The converted EXE looks like a sealed program, so people assume the script inside is locked away. It is not - it is carried inside the file, readable by anyone who cares to look. This page explains why, and the one rule that keeps you safe: no secrets in scripts, ever.
Here is a test worth doing once: take a script you converted, and treat the EXE the way a curious stranger would. The script text comes back out - complete, readable, comments and all. Conversion changes the packaging, not the privacy. Every claim in this page follows from that single fact, and it is the most important thing to understand before you hand a converted tool to anyone.
This page exists because the most dangerous misunderstanding about conversion is also the most common: the idea that converting a script to an EXE hides the code. It does not. Tools like PS2EXE carry your complete script inside the EXE, encoded (base64-style) so it travels as data. Encoding is not encryption. There is no key, no lock, and nothing to crack.
When the EXE runs, it must hand the readable script to the PowerShell engine - that is how the whole design works. Anything a program can read at run time, a determined person can also read: the text can be pulled from the file, caught while the program runs, or recovered with the same class of tools that created it. Assume anything inside a converted EXE is public.
Because the source is recoverable, a converted script must never contain:
This rule is not new with EXEs. A plain .ps1 is a text file anyone can open, so the rule always applied - conversion just tempts people to forget it, because the result looks like a sealed program.
If the task genuinely needs a secret, the secret must live outside the script:
Get-Credential, so the person running it supplies their own rights and nothing is storedEach option keeps the secret out of the distributed file, which is the only place it was ever in danger.
Sometimes the honest answer is that a script wrapper is the wrong technology. If the logic itself is the product - a tool you sell, or an algorithm a competitor should not see - write it in a compiled language such as C sharp, where the shipped file contains machine code and reading it back is real work. Even that is obfuscation, not absolute secrecy, but the gap between encoded script text and compiled code is the gap between a poster and a locked drawer.
For the everyday admin tools this guide is about, none of that is needed. Just keep secrets out, and the wrapper's openness costs you nothing.
Watch the video for the conversion itself - and keep this page's rule in mind for every script you convert after it.
Watch Full VideoNo. PS2EXE-style tools encode the script so it can be stored inside the program file and passed to the PowerShell engine at run time. Encoding has no key and no protection - it is the difference between writing a note in shorthand and locking it in a safe. Anyone can decode it in seconds.
Usually not. If the file contains no passwords, keys or private data, there is nothing sensitive to recover - anyone reading it just learns how your tool works. The rule only bites when a secret is inside, which is why the fix is simply to keep secrets out.
You can make it uglier, not safe. Obfuscators rename variables and scramble layout, which slows a casual reader and stops nobody determined - and the script must still become readable for the engine to run it. Treat obfuscation as tidiness, never as security, and never let it talk you into embedding a password.