How I Built My URL Decode Tool

I have been filling out Tools Online with the kind of developer utilities that are small, boring, and incredibly useful when you need them right now. A URL decode and encode tool was an obvious one to build. When you are debugging API calls, checking callback URLs, or trying to read a string full of %E4%B8%AD%E6%96%87, you usually do not want to open DevTools and write one more line of JavaScript. You just want a page that works immediately and keeps your data in the browser.

That was the whole goal here: make it fast, make it clear, and make it convenient enough that I would actually use it myself. If you want to see the finished version first, you can try it here: URL Decode tool.

What this tool does

The tool handles both sides of the workflow.

On the decode side, it takes percent-encoded content and turns it back into readable text with decodeURIComponent, which is useful when I am checking query params, callback links, or encoded values from logs.

On the encode side, I decided not to stop at a single output. The page shows both:

• encodeURI, for full URLs where the URL structure should stay intact
• encodeURIComponent, for parameter values where special characters should be fully escaped

That distinction matters a lot in real use. People often know they need “URL encoding,” but the difference between those two JavaScript APIs is exactly where mistakes happen. So the tool does not just convert text. It also explains the difference and shows when each option makes sense.

I also added the smaller quality-of-life pieces that make a tool like this feel complete:

• real-time conversion while typing
• a switch for turning real-time mode on or off
• one-click copy and paste support
• local history for recent conversions
• clear error feedback for invalid encoded input

None of that is flashy, but together it is much nicer than opening the console every time.

How I built it

My usual approach for tools like this is to build the smallest working loop first: input, processing, output. Once that works, I add the interaction details that actually affect usability.

The main component is a client-side React component. The logic is straightforward, but I still wanted the state model to be clean. I split state across the input value, decode output, encode output, current mode, error message, copy feedback, real-time toggle, and history. For the encode flow, I keep both uri and uriComponent outputs so the user does not need to make that choice after the fact.

History is stored in localStorage, capped at 20 entries. I also made sure it does not get noisy. If the latest entry is effectively the same input in the same mode, it is ignored. In real-time mode, I do not immediately save every keystroke either. I delay history writes slightly so the tool feels like a practical utility instead of a key logger with a UI.

On the page itself, I did not want a bare input box and a button. I wanted the landing page to be useful on its own, so I included content that explains the context around the tool:

• why URL encoding matters
• what RFC3986 allows and reserves
• common failure cases when text is not encoded properly
• the difference between encodeURI and encodeURIComponent
• a quick reference table for common encoded characters
• FAQ, how-to content, and structured SEO metadata

So the end result is not just a working widget. It is a tool page that helps people use the feature and understand the concept.

Where AI helped

This was not a one-prompt, fully automated build. I used AI more like a fast development partner. It helped me move faster, but I still made the decisions that shaped the final result.

The first place AI helped was requirement breakdown. I used it to quickly explore which interactions were worth including beyond basic encode and decode. Real-time conversion, clipboard actions, history, and dual encode outputs all came out of that early exploration phase.

Then I used AI to help draft an initial component structure. That is where it saves the most time for me: getting a first pass on state layout, processing flow, and UI structure so I can start refining instead of staring at a blank file.

After that, I tightened the implementation myself. Type details, state behavior, duplicate-history filtering, error handling, and the final interaction choices all needed manual judgment. This project also has real constraints around strict TypeScript, Radix UI usage, i18n file organization, and SEO page structure, so I treat AI output as a draft, not a final answer.

I also use AI later in the process for cleanup work:

• checking whether the copy reads naturally
• filling in page content that users and search engines actually benefit from
• catching obvious edge cases or missing explanations

That is the workflow I like most. AI handles the repetitive and exploratory parts. I keep control over the parts that determine quality.

The parts I like most in this tool

The first one is privacy. Everything runs in the browser. Nothing needs to be sent to a server. For a developer tool that often touches callback URLs, temporary tokens, or debugging data, that boundary matters.

The second one is that the page explains things instead of only outputting a result. I do not like tools that give you an answer without helping you understand why it works. So I added the encodeURI vs encodeURIComponent comparison, an encoding reference, and enough surrounding context to make the page useful even before someone clicks copy.

The third one is the multilingual and SEO work around it. The site supports 15 languages, so even a “small” utility ends up needing full component copy, landing-page content, FAQ, metadata, alternates, and JSON-LD. It is a lot of detail work, but it is worth it because a useful tool should be discoverable and understandable, not just functional.

Who this is for

This tool is especially handy if you regularly do things like:

• debug API parameters
• inspect OAuth or payment callback URLs
• deal with spaces, non-ASCII text, or special characters in query strings
• generate safe parameter values for URLs
• quickly decide whether a full URL or a single value should be encoded

It is the kind of page that saves time when you need a quick answer and do not want to drop into code just to inspect one string.

Final note

I do not think developer tools need to be complicated to be valuable. A lot of the time, the best ones are the pages you remember at exactly the moment you need them.

That is what I wanted this URL Decode and Encode tool to be. Not flashy, not overloaded, just fast, clear, and complete enough to be genuinely useful. AI helped me speed up parts of the build, which let me spend more time on the interaction details, page content, and overall polish.

If you spend any amount of time bouncing between encoded strings and readable URLs, this one should fit nicely into your workflow. If you want to open it right away, you can try it here.