I built a small AES tool because I got tired of rewriting debug scripts

Most of the time, AES debugging is not hard because the algorithm is hard. It is hard because the details are scattered.

Someone sends you a ciphertext, a key, an IV, and then a short note like "CBC + PKCS7, Base64 output". That should be enough, but in practice I still end up opening an old script, editing a few constants, running it, then doing the same thing again for the next integration.

So I built a small browser-based AES encryption and decryption tool for Tools Online:

https://toolsonline.run/aes

It is meant for everyday developer debugging, not for replacing production crypto code.

What I wanted it to solve

The annoying part of AES work is usually the parameter matrix:

- the key might be UTF-8, Hex, or Base64
- the IV might be present, missing, or not needed at all
- CBC, ECB, CFB, OFB, and CTR behave differently
- output may need to be Base64 or Hex
- padding mismatches often look like "nothing works"

So the tool puts those choices directly in the UI. You can switch between encrypt and decrypt, choose the AES mode, pick padding, change key and IV formats, generate a random key or IV, and copy the result without leaving the page.

One small detail I cared about: when ECB is selected, the IV field is disabled and the UI explains why. That sounds minor, but these are the exact details that reduce debugging confusion.

Why browser-only matters here

For a crypto utility, the implementation detail that matters most is where the data goes.

Keys, API payloads, logs, callback parameters, encrypted tokens: none of these should be casually sent to a random backend just because I need a quick decode or test encryption.

This AES tool runs in the browser. The input, key, IV, and output stay local. It is still a debugging helper, but at least it does not require uploading sensitive-looking text to a server.

How AI helped during the build

AI was useful for the boring-but-important parts: listing the mode and padding combinations, checking edge cases around key and IV formats, drafting the first version of the FAQ, and making sure the page explained why ECB is usually a bad choice for larger data.

The implementation still needed human cleanup: TypeScript types, UI state, copy/paste behavior, local history, multi-language content, and the final SEO page structure.

When I use it

I use it when I need to:

- compare AES outputs across modes
- verify third-party API encryption examples
- debug encrypted values from logs
- generate a quick test key or IV
- explain CBC vs ECB vs CTR to someone during integration

If you deal with encrypted payloads often, you can try it here:

https://toolsonline.run/aes

It is a small tool, but it removes one of those tiny workflow interruptions that keeps showing up during backend and API work.