The from-base64 operation decodes a Base64 value back into what it was. It is the reverse of to-base64.
How it works
Value: aGVsbG8= Result: hello
Value: MTIzNDU= Result: 12345
Value: eyJpZCI6MX0= Result: {"id":1}
Invalid input does not fail
This is the one to watch. Decoding something that is not Base64 does not produce an error and does not leave the value alone. Characters the decoder does not recognise are skipped and the rest is decoded anyway, so you get a shorter, meaningless string.
Nothing about that result announces itself as wrong. It is not empty, so a check for an empty value will not catch it, and it travels on to the advertiser looking like an ordinary value.
So only decode where you know the value is encoded. If a response sometimes carries Base64 and sometimes plain text, put a condition on the step rather than decoding everything and hoping.
When you need it
Reading a response that arrives encoded. Some APIs return a payload as Base64 and you want the contents.
Checking what is inside a token. The parts of a JWT are Base64, so decoding one shows you what it claims.
Recovering something you encoded earlier, when a later step in the same flow needs the original.
Binary data
Base64 can hold anything, including data that is not text. Decoding a file or an image into a field gives you bytes that make no sense as characters and will usually break whatever you send them to.
Decode into a text field only when you know the original was text.
Reference
See PHP: base64_decode.

