Input Decomposition and Protocol Completion
The URL parsing engine, the main feature of this tool, detects the string entered in the "Input URL to be analyzed" field in real time and decomposes it into individual components using the native JavaScript URL interface.
When the text in the input field is changed or the "Reparse" button is clicked, leading and trailing whitespace characters are trimmed first.
If the input value is completely empty or fails syntactic parsing, the states of all components (protocol, host, port, path, hash, and query parameter rows) along with any reconstructed output strings are cleared atomically.
This immediate reset prevents the display from persisting stale values or outdated parameter rows from a previously analyzed address.
In contrast, when hostless URLs such as file:///path parse successfully, their parsed breakdown fields and query rows remain intact for inspection, though reconstructed output remains empty because reconstruction strictly requires a host.
Output clears whenever current state is invalid.
If the user's input string lacks a protocol scheme such as http:// or https://, standard URL APIs treat it as a relative path or an invalid format, throwing a parsing error.
To circumvent this, the tool determines if the beginning of the string matches a protocol scheme. If no match is found, meaning the protocol is omitted, http:// is temporarily concatenated to the start of the string to create a pseudo-complete URL before passing it to the parsing process.
When scheme completion takes place during initial parsing, an omitted protocol defaults toward HTTPS priority so that the address can be parsed smoothly.
However, clearing the editable protocol field later does not retrigger this scheme inference. If native URL object creation fails during parsing due to malformed syntax, an error message is displayed on the screen, and all previous parsed component rows, breakdown fields, and derived outputs are cleared atomically.
Conversely, when hostless inputs like file:///path parse validly, their component fields are preserved on screen, but reconstructed output is withheld because the reconstruction engine requires a valid host.
Editing the Five Components
Once the URL is successfully parsed, the extracted information is immediately reflected in five independent input fields: Protocol, Host (domain/IP), Port, Path, and Hash (Fragment).
Note that any userinfo is not retained and is completely lost upon reconstruction. Users can freely reassemble the original URL structure by directly editing these input fields.
The reconstruction process works by assembling all active components into a complete URL string—combining the scheme, authority host, optional port, leading-slash normalized path, formatted query string, and hash fragment together first.
If a protocol string exists, a ':' and '//' are ensured before attaching the required host and any explicit port. If a path is present, a leading slash is prepended when missing.
Active query rows and hash fragments are attached directly to this assembled candidate. The entire assembled string is then passed as a single unified entity to the native new URL(candidate).href constructor to validate syntax and perform standard URL normalization across the whole address.
Because this validation happens on the entire constructed URL rather than validating base components in isolation before appending fragments, any invalid host, port, or malformed structure prevents output generation.
The reconstruction model requires a valid host alongside the protocol scheme (supporting standard and custom schemes such as HTTPS, FTP, or WebSocket) and executes synchronous validation through new URL(base).href on every edit.
Because each field modification immediately recomputes the target address, any invalid host, malformed port, or broken syntax halts reconstruction without displaying stale valid output from an earlier state.
Query parameter rows retain duplicate keys and their relative order, excluding disabled rows or empty key inputs, and encode parameters via URLSearchParams (encoding spaces as +, literal plus signs as %2B, and literal percent signs as %25).
Note that this process does not guarantee byte-for-byte identity or signed URL validity, nor does local syntactic parsing perform DNS resolution, network reachability checks, or endpoint security validation.
Adding, Duplicating, and Disabling Queries
Query parameters (the strings following the ? in a URL) are expanded into a dedicated table UI titled "List/edit query parameters." The parameters, decomposed using the URL object's searchParams property, are managed as independent row objects, each assigned a random string ID.
Here, even if multiple parameters share the same key name, they are extracted as separate rows rather than being compressed into an array, allowing you to edit them individually while maintaining their duplicates and order.
Each row features a toggle switch to enable or disable it, an input field for the key, an input field for the value, and a delete button.
Clicking the "Add parameters" button appends a new parameter row with an empty key and value at the end.
During reconstruction, parameters are filtered. First, parameters with their toggle switch turned off (disabled) are excluded from the concatenation process.
This allows you to remove them from the output URL without deleting the row entirely, which is useful for temporary toggling during testing.
Next, rows where the trimmed key name is empty are also excluded, regardless of whether a value is entered. However, if a key is present but the value is empty, it is not excluded and will appear in the reconstructed URL as ?key=.
The original keys are appended without additional trimming, preserving duplicates and order. Parameters passing these filters are sequentially appended via URLSearchParams, which re-percent-encodes the values (converting spaces to +, literal + to %2B, and literal % to %25) and attached to the end of the URL path.
Normalization and Loss of Authentication Information
During the parsing and reconstruction process of this tool, passing the input string through the browser's standard URL parsing API inherently applies a certain level of normalization (standardization) and causes specific information to be dropped.
The most noticeable loss involves authentication information (such as usernames and passwords used in Basic Authentication) embedded within the URL.
For example, if you paste https://username:password@example.com/ into the input field, the browser's URL object recognizes it internally.
However, the tool's UI elements lack dedicated fields to store or edit authentication info. Consequently, this data is not carried over into the UI state and is automatically dropped during decomposition.
The reconstructed URL will become https://example.com/, losing the original credentials.
Normalization also applies to port numbers. If the default port for a specified protocol (like 80 for http or 443 for https) is explicitly written in the input URL, the URL API specification may automatically absorb and omit this port information.
Conversely, non-ASCII characters or special symbols entered as plain text in the query parameter fields will be automatically and accurately percent-encoded when passing through the URLSearchParams.toString() process before appearing in the reconstructed output URL.
Component Encode and Decode
Independent of the overall URL parsing and reconstruction features, this tool provides a standalone "URL encoding/decoding" text conversion utility in the sidebar area.
Instead of handling entire URL components, this auxiliary feature executes encoding or decoding purely on partial strings manually entered by the user.
This utility directly utilizes the built-in JavaScript functions encodeURIComponent and decodeURIComponent. When the "Encoding" mode is selected, all characters in the input text—except for alphabets, numbers, and a specific set of symbols (`- _ .
! ~ * ' ( )`)—are converted into UTF-8-based percent encoding. Selecting the "Decoding" mode restores the percent-encoded string back to its original text.
A critical behavior to note here is the handling of the + (plus) symbol. While systems processing form submissions (application/x-www-form-urlencoded) encode an ordinary space (U+0020) as a + symbol and decode it back to a space, this utility strictly relies on decodeURIComponent.
Therefore, entering a + symbol for decoding will output it exactly as a + character, not a space. Spaces must be encoded and decoded as %20.
In the event that invalid percent-encoded text is submitted for decoding, the resulting exception error is displayed directly in the result field to prevent the process from halting.
Non-Support for Signed URLs, Safety, and Connections
This tool functions strictly as a local text editor specialized in the structural decomposition, editing, and concatenation of strings.
Therefore, it does not include features to verify whether the URL actually functions on the live internet.
Specifically, there are no capabilities to query DNS to confirm if the entered host name (domain) exists, nor are there reachability checks like sending HTTP requests to the assembled URL to verify status codes.
Furthermore, it lacks security scanning functions to determine if the destination website is safe (i.e., not malware or a phishing site).
Reconstructing a URL using this tool preserves duplicate parameters and their order, but may still cause changes due to user edits, query parameter normalization, encoding formats, or the loss of user information.
Consequently, these changes may invalidate any cryptographic signatures attached to the original URL if the signed components are altered.
This tool does not possess the capability to recalculate signatures, and no guarantees are provided regarding the validity of signatures in the reconstructed URL.