Encrypt text
Encryption done by somebody else's server is encryption that server watched. It held your message and your passphrase — the two things the exercise exists to protect. This runs in your tab, makes no request, and works and makes no request.
AES-256-GCM with the key derived from your passphrase, using your browser's own cryptography rather than anything hand-rolled.
There is no recovery. Lose the passphrase and the text is gone — that is what makes it encryption rather than a lock with a spare key somewhere.
AES-256-GCM, with the key derived from your passphrase by PBKDF2-SHA256 over 310,000 iterations. Authenticated, so an altered message fails to decrypt rather than quietly producing the wrong text.
Nothing is transmitted. Open the Network tab before you press encrypt and watch nothing happen.
This is the one page where "runs locally" is the whole product
Everywhere else on this site, processing locally is a strong convenience argument: it is faster, there are no limits, and your files stay yours. Here it is not an argument, it is the entire thing. An encryption tool that transmits your plaintext and your passphrase has not encrypted anything in any sense that matters — it has performed a demonstration of encryption while handing the inputs to a third party.
And you cannot tell which kind you are using by looking at the page. You can tell by opening the Network tab. That is the only claim here worth making, and it is checkable in five seconds.
What the parts do
| Part | Job |
|---|---|
| AES-256 | The cipher. Not going to be broken by anyone |
| GCM mode | Authenticates as well as encrypts, so tampering is detected |
| PBKDF2, 310,000 rounds | Turns a passphrase into a key, slowly, so guessing is expensive |
| Random salt | Means two people with the same passphrase get different keys |
| Random IV | Means the same message encrypts differently every time |
The salt and IV are stored in the output and are not secret — they cannot be, because decryption needs them. What must stay secret is the passphrase, and nothing else.
The passphrase is the weak link, and it is not close
Nobody is going to break AES-256. An attacker with your encrypted block will go after the passphrase instead, by guessing, and the entire security of the message rests on how hard that is.
The 310,000 hashing rounds exist precisely to slow that down — each guess costs real work rather than being instant. But slow guessing of a passphrase that appears on a wordlist is still successful guessing. Use something long and genuinely random; the password generator is next door and equally local.
Send the passphrase separately
The most common mistake with encrypted messages has nothing to do with the cryptography. It is emailing the encrypted block and the passphrase in the same message, which reduces the whole exercise to a mild inconvenience for anyone reading the mailbox.
Different channel, ideally a different medium: the block by email, the passphrase by phone or in person. And remember there is no recovery — if the passphrase is lost the text is genuinely unrecoverable, which is the point rather than a design flaw.
Questions
Is it safe to encrypt text on a website?
Only if the encryption happens in your browser, and on most sites it does not. If the text is sent to a server to be encrypted, that server has seen both your message and your passphrase — the two things encryption exists to protect. This page does it in the tab and makes no request, which you can confirm with the Network tab open and watch nothing leave.
What encryption does this use?
AES-256 in GCM mode, with the key derived from your passphrase using PBKDF2-SHA256 over 310,000 iterations. All of it is your browser’s built-in WebCrypto implementation rather than hand-written cryptography, which is the right choice — the fastest way to produce broken encryption is to implement it yourself.
What happens if I lose the passphrase?
The text is gone, permanently. There is no recovery, no reset and no back door, and that is what makes it encryption rather than a lock with a spare key in a drawer somewhere. Write the passphrase down somewhere safe before you encrypt anything you cannot afford to lose.
Why does the same text give a different result each time?
Because a fresh random salt and a fresh random initialisation vector are generated for every message. If encrypting the same text twice gave the same output, anyone watching could tell that you had sent the same message twice — and in GCM specifically, reusing an initialisation vector is catastrophic rather than merely untidy.
What if someone alters the encrypted message?
Decryption fails outright and says so. GCM is an authenticated mode: it verifies the message has not been changed before returning anything. A tampered message produces an error rather than plausible-looking wrong text, which is exactly what you want.
How strong should the passphrase be?
It is the weakest link by a wide margin — AES-256 is not going to be broken, so an attacker will go after the passphrase instead. Use a long random one from the generator, or a phrase of several unrelated words. The 310,000 hashing rounds make guessing slow, but they cannot rescue a passphrase that was on a wordlist.
What BriskFile will not do to you
-
Your files never leave your device
Every conversion runs in your browser. Open DevTools, watch the Network tab, and you will see no upload — because there is not one.
-
No account, no email, no watermark
Nothing to sign up for and nothing stamped on your images. There is no step between choosing a file and getting it back.
-
No limits at the download button
No daily cap, no file counter, no "upgrade to download". If the tool starts a job, it finishes it.
-
Checkable, not just claimed
Open the Network tab and convert something — nothing goes out. Or load the page, disconnect, and watch it keep working: the tool is already on your machine, and your file never leaves it.