Connection String Parser: Decode, Edit, and Rebuild Database Connection Strings
Connection String Parser breaks PostgreSQL, MySQL, MongoDB, Redis, and SQL Server connection strings into readable components so you can inspect, edit, and rebuild them — entirely in your browser.
Free Interactive Tool
Connection String Parser
Parse database connection strings (PostgreSQL, MySQL, MongoDB, Redis, SQL Server) into components, then edit fields and rebuild the string. Fully in-browser.
Table of Contents
Every production outage caused by a misconfigured DATABASE_URL starts the same way: a tiny string, stuffed with credentials, hosts, ports, and options, that nobody can read at a glance. Is the port wrong? Was the password percent-encoded? Did someone swap the username for the database name? Connection strings are dense by design, and that density makes them easy to break.
The Connection String Parser solves this by taking any database connection string — PostgreSQL, MySQL, MongoDB (including mongodb+srv), Redis, SQL Server, SQLite, AMQP, or a generic URL — and splitting it into labeled fields: scheme, username, password, host, port, database, and query parameters. It also understands libpq keyword/value strings and ODBC-style strings, so it covers the formats you actually encounter in the wild, not just URLs.
Because everything runs 100% client-side, nothing is ever uploaded. You can paste a real connection string from your environment, inspect it, fix a field, and copy the rebuilt result — even offline. In this guide, we'll walk through the tool's features, how to use it, and a practical tour of connection string anatomy across the three major formats.
Why Use Connection String Parser?
- Instant readability. Instead of squinting at a wall of scheme://user:pass@host:port/db?params, you get each component on its own labeled line. Debugging a failed connection takes seconds instead of minutes.
- Multi-dialect support. The tool auto-detects eight dialects — PostgreSQL, MySQL, MongoDB (with mongodb+srv), Redis, SQL Server, SQLite, AMQP, and Generic — so you don't have to tell it what you pasted.
- Three input styles. URL-style strings, libpq keyword/value strings (host=localhost port=5432 dbname=mydb), and ODBC keyword strings (Driver={...};Server=...;Uid=...;Pwd=...) all parse correctly.
- Safe with real credentials. Parsing happens in your browser; no network request carries your string. The password field is masked by default with a show/hide eye toggle for shoulder-surfing safety.
- Live rebuilding. Edit any field — swap the host, change the port, add sslmode=require — and the rebuilt connection string updates live. Copy it to your clipboard when it looks right.
- Edge cases handled. IPv6 hosts in brackets, the port-less mongodb+srv form, SQLite's sqlite:///path.db file paths, and PostgreSQL's socket-style postgresql:///dbname all parse as intended.
Key Features
| Feature | What it does |
|---|---|
| Auto dialect detection | Identifies 8 dialects: PostgreSQL, MySQL, MongoDB (incl. mongodb+srv), Redis, SQL Server, SQLite, AMQP, Generic |
| URL-style parsing | Parses scheme://[user[:pass]@]host[:port][/db][?params] using the WHATWG URL parser |
| libpq keyword/value parsing | Handles host=localhost port=5432 dbname=mydb user=app password=secret |
| ODBC keyword parsing | Handles Driver={...};Server=...;Database=...;Uid=...;Pwd=... |
| SQL Server URL style | Understands the tedious/mssql format sqlserver://host;database=db;user=...;password=... |
| Editable fields | Modify username, host, port, and database directly |
| Options management | Add, edit, or delete query parameters such as sslmode=require |
| Live rebuild + copy | Regenerates the connection string as you type; one click to copy |
| 100% client-side | Nothing is uploaded; works offline |
A few of these deserve a closer look:
- The WHATWG URL parser is the secret weapon. It's the same algorithm browsers use, which means percent-encoding, bracketed IPv6 hosts, and empty-component edge cases are handled to spec rather than by regex guesswork.
- Options are first-class citizens. Many parsers stop at host and port. Here, the query parameter section becomes an editable list — add sslmode=require for a managed Postgres, drop connectTimeout for a flaky network, and watch the string rebuild itself.
- Masking by default. Real connection strings contain real passwords. The parsed password field is hidden behind an eye toggle, so sharing your screen during a debug session doesn't leak credentials.
How to Use
- Open the Connection String Parser.
- Paste your connection string into the input box. It can be a URL-style string, a libpq keyword/value string, or an ODBC-style string — the tool detects the format automatically.
- Inspect the parsed output. The string breaks into scheme, username, password (masked), host, port, database, and a list of options. Toggle the eye icon if you need to see the password.
- Edit what needs fixing. Change the host to point at staging, bump the port, rename the database, or add/edit/delete connection options.
- Copy the rebuilt string from the output field and paste it wherever it's needed — an env var, a config file, or a deployment dashboard.
Understanding Connection String Anatomy
Most developers use connection strings daily without ever formally learning their grammar. Here's the full breakdown, component by component.
Scheme. The prefix before :// declares both the protocol and the family: postgresql://, mysql://, mongodb://, redis://, amqp://. Variants carry meaning — postgresqls or a sslmode parameter signals TLS, and mongodb+srv means "resolve hosts from a DNS SRV record," which is why it never includes a port.
Credentials. Between :// and the host sits username:password@. The colon is optional when there's no password; the whole pair is optional for databases with trust or IP-based auth. Special characters must be percent-encoded — p@ssword becomes p%40ssword — and an unencoded @ is the classic cause of a mangled host. In libpq style, credentials appear as user=app password=secret; in ODBC, as Uid=...;Pwd=....
Host. The server's address: a domain, an IP, a bracketed IPv6 literal like [::1], or for SQLite, a file path. Omit the host entirely in PostgreSQL's socket form (postgresql:///mydb) to connect over the default Unix socket. In ODBC this is Server=...; in libpq, host=....
Port. The TCP port after the colon — 5432 (PostgreSQL), 3306 (MySQL), 27017 (MongoDB), 6379 (Redis), 1433 (SQL Server). Omit it to use the dialect's default. Note that mongodb+srv never carries a port, and an unencoded : inside a password will silently corrupt this field.
Database. The path segment after the first / — postgresql://localhost:5432/appdb. For SQLite, this is where the file path lives (sqlite:///data/app.db). ODBC calls it Database=...; libpq calls it dbname=....
Options (query parameters). Everything after ? is a key=value list joined by & — ?sslmode=require&connect_timeout=10. These tune TLS, timeouts, pooling, and replica-set behavior. Postgres parameters map to libpq keywords, so ?sslmode=require in a URL equals sslmode=require in keyword form — handy when converting between formats.
The three input styles are worth seeing side by side. A URL-style string reads postgresql://app:[email protected]:5432/appdb?sslmode=require. The same connection in libpq keyword/value form is host=db.example.com port=5432 dbname=appdb user=app password=secret sslmode=require. And the ODBC form for a SQL Server connection looks like Driver={ODBC Driver 18 for SQL Server};Server=db.example.com;Database=appdb;Uid=app;Pwd=secret. All three describe the same thing — a server, a database, and who's asking — and the parser normalizes all of them into the same editable field set.
Practical Use Cases
Rotating credentials across environments
You've got a production string, a staging string, and a local string that should differ only in host and credentials. Paste each one into the parser and compare fields side by side — the one-line difference you can't see in a 120-character string jumps out immediately in labeled fields. When the password rotates, type the new one into the password field and copy the rebuilt string to every config that needs it.
Converting between formats
Migrating an app from a URL-based driver to a libpq-based one (or filling in an ODBC DSN) usually means manually re-transcribing every component — and every transcription is a chance to fat-finger the port. Parse the source string, read off the components, and rebuild in the target format with confidence. The SQL Server URL style used by tedious/mssql (sqlserver://host;database=db;user=...;password=...) is notoriously easy to mangle by hand, so let the parser split it first.
Debugging "connection refused" and "authentication failed"
Half of all connection errors are structural: a percent-encoded @ in the password swallowing the host, a missing port falling back to the wrong default, or a stray ? truncating the database name. Parsing the exact string that's failing — not the one you think you deployed — shows you what the driver actually sees. Often the fix is obvious the moment the components are labeled.
Building a connection string from scratch
Instead of assembling a string character by character and hoping, work in reverse: type the host, port, and database into the editor, add the options you need (like sslmode=require for a managed database), and let the tool assemble a syntactically correct string. Copy it straight into your .env file.
Best Practices
- Never store unencrypted passwords in plain connection strings in source control. Use env vars or a secrets manager, and treat any string you paste into the parser as sensitive — the tool is client-side, but your clipboard history is yours to manage.
- Percent-encode special characters in credentials. An @, :, /, or # inside a username or password will silently restructure the string. When in doubt, encode it.
- Prefer named options over implicit defaults. Writing port=5432 explicitly costs nothing and makes the string self-documenting when someone parses it six months later.
- Keep one canonical string per environment instead of slightly different copies scattered across configs — drift between copies is where outages are born.
- Add sslmode=require (or your dialect's TLS equivalent) for anything crossing the public internet; most managed providers reject or warn on plaintext connections anyway.
- Parse before you paste into tickets. When asking for help, sharing the parsed components (with the password masked, as the tool does by default) communicates far more than a raw string ever could.
Ready to Fix That Connection?
The next time a connection string fights you — whether it's a percent-encoding puzzle, a format conversion, or a host that looks right but refuses connections — don't eyeball it. Paste it into the Connection String Parser, watch it break into labeled components, fix the one field that's wrong, and copy a rebuilt string you can trust. It's free, works offline, and never sends your data anywhere. Your database credentials are already sensitive enough; debugging them shouldn't require shipping them to a server, too.
Related Tools You Might Like:
Happy parsing!
Frequently Asked Questions
Q: Is my connection string sent to a server?
A: No. Parsing, editing, and rebuilding all happen in your browser with JavaScript. No network request carries your string, and the tool works with your internet connection disabled — try it.
Q: Which connection string formats are supported?
A: URL-style strings (scheme://user:pass@host:port/db?params) for PostgreSQL, MySQL, MongoDB and MongoDB+SRV, Redis, SQL Server (including the tedious/mssql sqlserver://host;database=... style), SQLite, and AMQP — plus libpq keyword/value strings and ODBC keyword strings. Unrecognized schemes fall back to a Generic parse.
Q: Can I edit the parsed fields or just view them?
A: You can edit username, host, port, and database, and add, change, or delete connection options. The string rebuilds live as you type, and a copy button puts the result on your clipboard.
Q: How are passwords handled in the UI?
A: The parsed password field is masked by default, with an eye toggle to reveal or re-hide it. That makes the tool safe to use while screen-sharing or taking screenshots — the reveal is deliberate.
Q: What about IPv6 hosts and other edge cases?
A: The tool uses the WHATWG URL parser — the same one browsers use — so bracketed IPv6 literals like [::1], the port-less mongodb+srv form, SQLite file paths like sqlite:///path.db, and PostgreSQL's socket-style postgresql:///dbname are all parsed according to spec.