{"id":51238,"date":"2026-03-16T16:06:24","date_gmt":"2026-03-16T20:06:24","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=51238"},"modified":"2026-03-16T16:07:14","modified_gmt":"2026-03-16T20:07:14","slug":"url-nsurl-double-encodes-characters-unnecessarily","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/03\/16\/url-nsurl-double-encodes-characters-unnecessarily\/","title":{"rendered":"URL\/NSURL Double-Encodes Characters Unnecessarily"},"content":{"rendered":"

Jeff Johnson<\/a>:<\/p>\n

\n

The older, simpler API [NSURL URLWithString:URLString]<\/code> behaves the same as [NSURL URLWithString:URLString encodingInvalidCharacters:YES]<\/code> when your code is compiled with the iOS 17 or macOS 14 SDK. So much for backward compatibility! [NSURL URLWithString:URLString]<\/code> continues to work fine with example 1, leaving the URL string untouched, but it mangles example 2:<\/p>\n

https:\/\/example.org?url=https%253A%252F%252Fexample.org%253Ffoo%5B0%5D%253Dbar<\/code><\/blockquote>\n

Notice that the brackets are encoded as %5B<\/code> and %5D<\/code>, which is good, but the preexisting %<\/code> characters are also encoded as %25<\/code>, thereby transforming %3A<\/code> (an encoded :<\/code> character) into %253A<\/code>, which is bad, indeed bonkers! The %<\/code> characters did not need to be encoded, because they are already valid characters in a URL query.<\/p>\n<\/blockquote>\n\n

I’ve seen other weird behavior, even using an old SDK, such as NSURLComponents<\/code> returning nil<\/code> instead of a valid URL.<\/p>\n\n

Previously:<\/p>\n