Connection String Builder & Validator

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.

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.

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.

How to use this tool

1. Build mode: pick a database preset, fill in the fields, and click Build connection string.
2. Parse / Validate mode: paste an existing connection string and click Parse & validate to see its parts and any flagged issues.
3. Use the copy button to grab the result for your appsettings.json, Key Vault secret, or environment variable.