SQL Server Connection String Examples

The same six or seven key=value pairs, rearranged slightly for every auth method. Here's a working example of each, and the two settings that cause the most support tickets on Azure SQL.

reference guide SQL Server Azure SQL

// anatomy

│

A connection string is a semicolon-separated list of Key=Value pairs. Order doesn't matter, keys aren't case-sensitive, and most drivers tolerate a handful of alternate spellings for the same key (User Id / UID, Server / Data Source). What changes between the examples below is only which keys are present.

// sql authentication

│

A username and password stored on the SQL Server instance itself, independent of Windows or Azure AD accounts. Most common for on-prem servers and for services that shouldn't have a domain identity.

example

Server=tcp:myserver.database.windows.net,1433;Database=StoredValueDb;User Id=app_user;Password=***;Encrypt=True;

// windows / integrated authentication

│

The connecting process's Windows identity is passed through — no username or password in the string at all. Only works when the app and the SQL Server are on the same domain (or a trusted one), which rules it out for most cloud-hosted apps talking to Azure SQL.

example

Server=localhost\SQLEXPRESS;Database=StoredValueDb;Integrated Security=True;Encrypt=False;

// azure ad variants

three flavors

Defaulttries managed identity, then environment credentials, then a chain of fallbacks — the right choice for apps already running in Azure

Interactivepops a browser login prompt — for local development, never for a running service

Passworda literal Azure AD username/password in the string — works, but is being phased out in favor of the above two wherever possible

example (Active Directory Default)

Server=tcp:myserver.database.windows.net,1433;Database=StoredValueDb;Authentication=Active Directory Default;Encrypt=True;

// what trips people up on azure sql

Azure SQL rejects connections without Encrypt=True. It's not optional the way it is for an on-prem server — a connection string that works fine locally against SQL Express will fail outright against *.database.windows.net until this is set.

TrustServerCertificate=True skips certificate validation entirely — it's a workaround for a self-signed cert on a local dev instance, not something that belongs in a connection string pointed at a real Azure SQL server. Its presence there is usually a leftover from copy-pasting a local dev string.

Integrated Security and a User Id/Password in the same string don't combine — one wins silently depending on the driver, and it's easy to leave stale credentials in a string after switching an app to Windows auth without noticing they're now ignored.

// try it yourself

│

Build a connection string for any of these auth methods, or paste an existing one to see it broken into fields (with the password masked), using the Connection String Builder — it also flags the Azure SQL/Encrypt mismatch above automatically.