Connection String Builder & Validator
Build a connection string from form fields, or paste one to parse its parts and flag common misconfigurations like a missing Encrypt=True or a plaintext password.
What this tool does
Build a connection string from form fields for SQL Server, Azure SQL, PostgreSQL, MySQL, or Cosmos DB — or paste an existing connection string to parse it into its individual parts and flag common misconfigurations. Everything runs in-memory within your active session; your server names, credentials, and keys are never sent to a separate API, written to disk, or logged.
Anatomy of a connection string
Every connection string is a flat list of semicolon-separated Key=Value pairs — no nesting, no quoting rules beyond escaping a literal semicolon. A typical SQL Server string breaks down like this:
Worked example — build
Choosing Azure SQL, entering server myserver.database.windows.net, database AppDb, user appuser, and a password generates:
Server=tcp:myserver.database.windows.net,1433;Initial Catalog=AppDb;Persist Security Info=False;User ID=appuser;Password=<your-password>;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Notice Encrypt=True and TrustServerCertificate=False are always included for the Azure SQL preset — Azure SQL requires an encrypted connection, so this tool doesn't let you turn it off for that preset.
Worked example — parse & validate
Pasting Server=localhost;Database=AppDb;User Id=sa;Password=P@ssw0rd; into Parse / Validate mode detects it as SQL Server and flags two issues:
This connection string contains a plaintext credential. Avoid committing it to
source control — use a secrets manager, .NET User Secrets, or an environment
variable instead.
Encrypt=True is missing or disabled — the connection may be vulnerable to
interception. Add Encrypt=True unless you have a specific reason not to.Why Encrypt=True and TrustServerCertificate matter
Encrypt=True wraps the connection in TLS so credentials and query data can't be read by anyone positioned between your app and the database server. Azure SQL has required it since 2022; on-prem SQL Server still defaults to unencrypted unless you set it explicitly. TrustServerCertificate=True skips validating that certificate against a trusted root — it's a common workaround for local development against a SQL Server instance using a self-signed certificate, but it defeats the point of encryption if left on in production, since it allows a machine-in-the-middle to present any certificate at all.
How encryption settings differ by database
The same encrypt-but-don't-verify pattern shows up under a different parameter name in every driver:
| Aspect | SQL Server / Azure SQL | PostgreSQL (Npgsql) | MySQL (MySqlConnector) |
|---|---|---|---|
| Enable TLS | Encrypt=True | SSL Mode=Require | SslMode=Required |
| TLS without validating the certificate (dev only) | Encrypt=True;TrustServerCertificate=True | SSL Mode=Require — requires TLS but does not validate the certificate | SslMode=Required — same behavior, no certificate validation |
| Full certificate validation | Encrypt=True;TrustServerCertificate=False | SSL Mode=VerifyFull | SslMode=VerifyFull |
| Server/host parameter | Server / Data Source | Host | Server |
| Credential parameters | User Id / Password | Username / Password | Uid / Pwd |
Why plaintext passwords in connection strings are a real risk
A connection string with a literal password is the single most common way database credentials end up committed to a public GitHub repository. This tool flags any parsed connection string containing a Password, Pwd, or AccountKey value (unless Windows/Integrated Security is in use) as a reminder to move it to dotnet user-secrets for local development, or Azure Key Vault / App Service Application Settings for production — never a literal value in appsettings.json that gets committed to source control.
Common connection failures
These are the runtime errors a misconfigured connection string like the ones above actually produces once your app tries to connect:
| Error | Cause | Fix |
|---|---|---|
| "A network-related or instance-specific error occurred while establishing a connection to SQL Server" | The server is unreachable — wrong host, wrong port, or a firewall blocking the connection | Verify the Server/Data Source value and that the server accepts remote connections |
| "Cannot open database "X" requested by the login" | The database name is misspelled, doesn't exist, or the login lacks access to it | Check the Database/Initial Catalog value against an existing database |
| "Login failed for user 'X'" | Wrong username or password, or SQL authentication isn't enabled on the server | Verify User Id/Password, or use Integrated Security for Windows authentication |
| "The certificate chain was issued by an authority that is not trusted" | Encrypt=True with TrustServerCertificate=False against a server using a self-signed certificate | Use a properly signed certificate in production, or set TrustServerCertificate=True for local development only |
How to use this tool
- Build mode: pick a database preset, fill in the fields, and click Build connection string.
- Parse / Validate mode: paste an existing connection string and click Parse & validate to see its parts and any flagged issues.
- Use the copy button to grab the result for your
appsettings.json, Key Vault secret, or environment variable.
Connection string
Result