This can be closed, thank you!

disagree or can we close it?

URLDecode works as expected and work the same way as in AC

https://trycf.com/scratch-pad/gist/adc141f39377d112c5f37f457130c225

I think this only came up because I had it in my head from some Lucee docs that URLDecode() should be avoided in favor of ESAPIEncode/Decode, but now I can't find it. If there's no push to stop using one and start using the other then it's a non-issue since, as you pointed out, they're not doing the same thing.

This came up for us in transmitting base64-encoded strings to clients for HTTP headers. + is valid there and so we'd just encode it, and had to use URLDecode – ESAPIEncode worked fine but the decode did indeed double-decode it.

Wouldn't hurt to have the docs point that out since I keep leaving my java interface manual in my other pants.

I left a comment on Slack too, but I believe this is intentional and more/less in the ESAPI docs. URL Decoding includes canonicalization which removes any double encoded bits of your string. Since a plus sign is a way to encode a space, the plus gets turned into a space for you. I'm fairly sure that's what your hitting. It also means this function is not really suited for a generic encode/process capable of handling any string, but instead can throw away information in some cases and is more suited only for strings in which you would never ever expect to see any meta characters, and if any were found, you would be ok with them being discarded.