Database Connection String Parser and Builder

Features

• Two modes: parse a string, or build one from fields
• Four targets: PostgreSQL, MySQL, MongoDB and Redis, each with its own default port
• Accepts both the URL form and libpq-style key=value
• Special characters in the password are percent-encoded; parsing decodes them again
• Warns when a password looks already encoded, so `%40` never becomes `%2540`
• Recognises sslmode / ssl-mode / tls parameters and lists each one
• Redis switches to the `rediss://` scheme for TLS
• Copy any single row, or all of them

How to use

1. Choose Parse or Build
2. Parse: paste a connection string and the fields appear at once
3. Build: pick a target and fill in host, port, database and password
4. Switch the SSL requirement if needed and the string updates live

FAQ

My password looks right but the connection fails. Why?

Usually double encoding. When building, the tool turns `@` into `%40`; if the string already contained `%40` (say, copied from another tool), encoding again produces `%2540`, and the server receives a password different from the one you set. This tool warns when the input contains `%XX` — when it does, enter the decoded plaintext instead.

Why is the parsed password shown as plaintext?

Because the string stores the encoded form while the value you need to check is the one set in the database. The tool decodes once on parsing, so `p%40ss` shows as `p@ss`. It only reverses the string’s own encoding, and changes nothing else.

The key=value form has no scheme — how is the database type known?

From the Target database dropdown. The URL form carries a scheme (`postgres://`, `redis://`…) that can be detected; the key=value form is a libpq / JDBC conninfo with no database type in it, so your selection decides.

Is anything uploaded?

No. Parsing and building run entirely in the browser; the connection string (password included) never leaves your device and no request is made.