connection-string-builder

Build a SQL Server connection string field by field, or paste an existing one to see it broken down. Runs entirely in your browser.

client-side only SQL Server no signup

build.env — fill in the fields

Server

Database

Authentication

User Id

Password

Encrypt = True (required for Azure SQL, recommended everywhere since .NET 6 default)

TrustServerCertificate = True (dev/local only — skips cert validation)

MultipleActiveResultSets = True (needed for some EF Core scenarios)

Connect Timeout (seconds)

Application Name

output — generated connection string

Fill in the fields on the left, then click "Build string".

parse.env — or paste an existing connection string

// things this catches

│

A few mistakes show up constantly in .NET connection strings, so the builder flags them as you go rather than letting you find out at runtime.

Encrypt not set for Azure SQL. Azure SQL rejects unencrypted connections outright — if your server host contains database.windows.net and Encrypt is off, that's almost always a bug, not a choice.
TrustServerCertificate=True in what looks like a production host. It's the right call for a local Docker SQL instance with a self-signed cert; it's a silent security hole if it ships to prod by accident.
Both Integrated Security and a User Id set. These are mutually exclusive — the driver will ignore one, and it's rarely obvious which.
Since .NET 6, Microsoft.Data.SqlClient defaults Encrypt to True and TrustServerCertificate to False — a connection string that worked under .NET Framework's older client can suddenly fail after a migration purely because of this default flip. Worth checking explicitly rather than assuming the old string still behaves the same way after upgrading.

// why "just paste it from Azure Portal" isn't always enough

│

The Azure Portal's connection string blade gives you a string that's syntactically correct but not always what you want to run with — it typically enables Encrypt but leaves the auth block as a placeholder, and it won't reflect an Azure AD identity setup even if that's actually how your app authenticates in production. Treat it as a starting template, not the final string.