Connection String Builder

A connection string is a compact line of text that tells a client library how to find a database or service and how to authenticate to it. Instead of scattering the host, port, credentials, and options across many settings, a driver reads a single string and negotiates the connection from it.

Most connection strings encode the same handful of ideas:

• Where — the server/host, and often a port or instance name.
• What — the database, catalog, or default schema.
• Who — a username and password, or an integrated / passwordless identity.
• How — options such as encryption, certificate trust, timeouts, pooling, and retries.

Two broad syntaxes dominate. The key-value (ADO.NET) style — Key=Value;Key=Value; — is used by SQL Server, PostgreSQL (Npgsql), MySQL, SQLite, Oracle, and the Azure services. The URI style — scheme://user:password@host:port/path?options — is used by MongoDB and RabbitMQ. Redis uses a small comma-separated format of its own. This builder handles all three.

1. Pick a provider card (SQL Server, PostgreSQL, MongoDB, …).
2. Click a preset such as Local Development, Docker, or Production, or fill in the fields directly.
3. Watch the connection string regenerate live, with inline validation and warnings.
4. Use Explain connection string to see what every property means, then Copy or Download the result.
5. Already have a string? Expand Import an existing connection string, paste it, and the form is populated for editing.

SQL Server uses the key-value format. The modern Microsoft.Data.SqlClient driver defaults Encrypt to True, so you usually decide only how the certificate is validated.

Server=localhost;Database=MyDatabase;User Id=sa;Password=***;Encrypt=True;TrustServerCertificate=True;

Use Integrated Security=True for Windows authentication (no password), host\\instance for a named instance, and host,port for a non-default port. In production, set TrustServerCertificate=False and use a trusted certificate.

The Npgsql .NET driver reads a key-value string. PostgreSQL always requires a target database, and SSL behavior is controlled by SSL Mode.

Host=localhost;Port=5432;Database=mydb;Username=postgres;Password=***;SSL Mode=Prefer;

SSL Mode=Prefer silently falls back to an unencrypted connection, so use Require or VerifyFull for managed services such as Supabase, Neon, RDS, or Azure Database for PostgreSQL. Many tools also accept the postgresql://user:pass@host:5432/db URI form, which this builder imports.

MySQL and MariaDB use the classic Uid/Pwd keys (or the equivalent User Id/Password).MySqlConnector is the recommended modern async driver.

Server=localhost;Port=3306;Database=mydb;Uid=root;Pwd=***;

In MySQL a “database” and a “schema” are the same thing. Add SslMode=Required (or stronger) whenever traffic crosses a network.

MongoDB uses a URI. Standard deployments use mongodb:// with an explicit host and port; MongoDB Atlas uses mongodb+srv://, which resolves the servers and options from DNS and enables TLS by default.

mongodb://username:password@localhost:27017/mydb

mongodb+srv://username:[email protected]/mydb?retryWrites=true&tls=true&authSource=admin

Usernames and passwords are percent-encoded automatically, so characters like @, :, and / in credentials won't break the URI.

The .NET StackExchange.Redis client uses a comma-separated configuration: the endpoint first, then options.

localhost:6379,password=secret,abortConnect=False

Set ssl=True and use port 6380 for a cloud cache such as Azure Cache for Redis. abortConnect=False is a common resilience default that lets the client keep retrying if Redis is briefly unavailable at startup. Other clients (ioredis, redis-py) prefer the redis:// URI form.

RabbitMQ uses an AMQP URI. Use amqp:// for plain connections and amqps:// for TLS.

amqp://user:password@localhost:5672

The default port is 5672 (5671 for TLS) — not the 15672 management UI port. The virtual host is appended as a path segment; the default vhost / is URL-encoded as %2F. The built-in guest user can only connect from localhost.

Azure SQL uses the same key-value format as SQL Server, with the server wrapped as tcp:host,1433 and encryption always on.

Server=tcp:server.database.windows.net,1433;Initial Catalog=Database;Persist Security Info=False;User ID=user;Password=***;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

Keep Encrypt=True and TrustServerCertificate=False — Azure presents a CA-signed certificate that should be validated. For production, prefer Microsoft Entra (Azure AD) authentication or a managed identity so no password lives in the string.

An Azure Storage account connection string carries the protocol, account name, shared key, and endpoint suffix.

DefaultEndpointsProtocol=https;AccountName=mystorageaccount;AccountKey=***;EndpointSuffix=core.windows.net;

The account key grants full control of the account, so treat it like a root password. Prefer a SAS token or DefaultAzureCredential (Microsoft Entra) in production, and rotate keys regularly. The EndpointSuffix changes for sovereign clouds (Azure China, US Government).

Azure Cosmos DB (NoSQL / Core SQL API) uses an account endpoint plus a key.

AccountEndpoint=https://example.documents.azure.com:443/;AccountKey=***;

This is the primary connection string from the Portal's Keys blade. As with storage, prefer a resource token or an Entra role for least-privilege access instead of the master key.

• Leaving encryption off. Forgetting Encrypt=True, SSL Mode=Require, or amqps:// sends credentials in clear text over the network.
• Trusting every certificate in production. TrustServerCertificate=True encrypts the traffic but disables validation, which enables man-in-the-middle attacks.
• Not URL-encoding credentials in URIs. A password containing @, :, /, or ?breaks a MongoDB or RabbitMQ URI unless it's percent-encoded (this tool does it for you).
• Confusing ports.RabbitMQ's AMQP port is 5672, not the 15672 management UI; TLS Redis is usually 6380, not 6379.
• Using admin accounts. Shipping with sa, root, or postgres instead of a least-privilege application user.
• Committing secrets. Hard-coding passwords and account keys into appsettings.json and pushing them to version control.

• Encrypt in transit.Always enable TLS for connections that leave the local machine, and validate the server's certificate in production.
• Prefer passwordless auth. Windows/Integrated authentication, Microsoft Entra, and managed identities remove the secret from the connection string entirely.
• Least privilege. Create a dedicated application account with only the permissions it needs.
• Keep secrets out of code. Load connection strings from environment variables, user secrets, or a vault (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault) — never from source-controlled files.
• Rotate credentials. Rotate passwords and account keys on a schedule, and immediately after any suspected exposure.

This tool never transmits what you type — see the note in the generator — but the strings it produces still contain live secrets, so handle the output carefully.

Yes. Every part of this tool — building, parsing, validating, and explaining — runs locally in your browser with JavaScript. No account or server-side processing is involved, and nothing you enter, including passwords and account keys, is uploaded, logged, stored in localStorage or cookies, sent to analytics, or placed in the URL.

What is a connection string?

A connection string is a single line of text that tells a client library how to reach a database or service and how to authenticate. It bundles the server or host, the database or catalog, credentials, and options such as encryption, timeouts, and pooling into one string that a driver parses at connect time.

How do I create a SQL Server connection string?

Select SQL Server above, then set the Server (e.g. localhost or host\instance), the Database, and either a User Id and Password or Integrated Security for Windows authentication. A typical result is Server=localhost;Database=MyDatabase;User Id=sa;Password=***;Encrypt=True;TrustServerCertificate=True;. The tool updates it live as you type.

What is Encrypt=True?

Encrypt=True tells the SQL Server client to negotiate a TLS-encrypted connection so credentials and data are not sent in clear text. The modern Microsoft.Data.SqlClient driver defaults Encrypt to True, and it is strongly recommended for any connection that leaves the local machine.

What is TrustServerCertificate?

TrustServerCertificate controls whether the client validates the server's TLS certificate against a trusted certificate authority. TrustServerCertificate=True skips that check — convenient for local development with a self-signed certificate, but insecure in production because it allows man-in-the-middle attacks. Use False with a properly trusted certificate in production.

How do I connect to PostgreSQL?

Choose PostgreSQL and set Host, Port (5432 by default), Database, Username, and Password. Set SSL Mode to Require or VerifyFull for anything over a network. The Npgsql-style result looks like Host=localhost;Port=5432;Database=mydb;Username=postgres;Password=***;SSL Mode=Prefer;.

How do I connect to MongoDB Atlas?

Select MongoDB and switch the scheme to mongodb+srv://. Enter your cluster hostname (for example cluster0.abcde.mongodb.net), your username and password, and set Auth Source to admin. TLS is enabled by default for SRV connections. The username and password are URL-encoded automatically so special characters don't break the URI.

How do I connect to Redis?

Choose Redis and set the Host and Port (6379, or 6380 for TLS). Add a Password if the server uses AUTH, and enable TLS for a cloud cache such as Azure Cache for Redis. The StackExchange.Redis format is localhost:6379,password=secret,abortConnect=False. Many other clients accept the redis:// URI form instead, which this tool also imports.

How do I connect to RabbitMQ?

Select RabbitMQ and set the username, password, host, and port (5672 for amqp, 5671 for amqps). Use amqps:// for TLS over a network. The result is a URI like amqp://user:password@localhost:5672. Credentials and the virtual host are URL-encoded automatically, so the default vhost / becomes %2F.

How do I connect to Azure SQL?

Choose Azure SQL and enter the logical server (ending in .database.windows.net), the database (Initial Catalog), and a User ID and Password. The tool produces Server=tcp:server.database.windows.net,1433;Initial Catalog=Database;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; — the ADO.NET string shown in the Azure Portal. For production, prefer Microsoft Entra authentication over a password.

Should passwords be stored in connection strings?

Avoid committing passwords in connection strings to source control. A connection string stores its password in plain text, so keep the string in a secret manager, environment variable, or a service like Azure Key Vault or AWS Secrets Manager. Better still, use passwordless authentication — Windows/Integrated auth, Microsoft Entra, or a managed identity — so no secret lives in the string at all.

How do I secure connection strings?

Enable encryption (Encrypt=True, SSL Mode=Require/VerifyFull, tls=true, amqps://), validate server certificates in production, use least-privilege accounts instead of sa/root/postgres, and keep the string out of code and version control by loading it from configuration or a secret store. Rotate credentials and account keys regularly.

Is this connection string builder private?

Yes. Everything — building, parsing, validating, and explaining — runs locally in your browser with JavaScript. Nothing you type, including passwords and account keys, is uploaded, logged, stored, or added to the URL.