What is the format of a DATABASE_URL?

scheme://user:password@host:port/database?option=value. The scheme identifies the database (postgresql, mysql, mongodb, redis), the credentials and host locate and authenticate, the path is the database name, and the query string carries options like sslmode. Special characters in the password must be URL-encoded - this tool handles that for you in both directions.

Why does my password break the connection string?

Because characters like @, :, /, and # have structural meaning in a URL, so a password containing them is misread - the @ in a password, for example, looks like the separator between credentials and host. The fix is URL-encoding (percent-encoding) those characters. The builder encodes the password automatically; the parser decodes it back so you can read the real value.

Is it safe to paste a connection string here?

The tool runs entirely in your browser - nothing is uploaded. That said, a real connection string is a live credential: avoid pasting production secrets into any web tool, and never commit a DATABASE_URL to your repo. Keep it in an environment variable or a secret store, which is also what a connection string is meant for.

Free tool · Runs in your browser · Nothing uploaded

DATABASE_URL, both ways.

Build a connection string from its parts, or paste one to decode it — for PostgreSQL, MySQL, MongoDB, or Redis. Correct scheme, default port, and the URL-encoding that trips everyone up, handled in both directions.

Database

Host

Port

User

Password

Database / name

Options (key=value&...)

Paste a connection string

A small thing that breaks a lot

The DATABASE_URL is your app's single most important piece of configuration — the one line that tells it where its data lives — and it breaks for boring reasons: a special character in the password that wasn't encoded, the wrong scheme, a missing port, an option in the wrong place. This handles all of that mechanically, so the string is right the first time and you can get back to the actual work.

It's also a live credential, which is the real point: a connection string belongs in an environment variable or a secret store, never in your repo or a screenshot. Where your secrets live, who can read them, and proving they haven't leaked is part of running a backend responsibly — and part of what a control plane keeps honest on the infrastructure you own.

Related free tools

Production-ready checkerScore your deploy Deploy error decoderDecode any deploy error Downtime cost calculatorPrice your downtime Uptime SLA calculatorWhat each SLA allows

All free tools →

The string is config. The secret is yours.

Infraveil runs your backend on servers you own, with credentials managed and access proven — so the connection between your app and its data is one you control and can audit, not one scattered across configs and chat logs.

See how it works

Get the backend-config playbook

Secrets, connection strings, and config done safely for a backend you run yourself. No spam.