C# appsettings.json Generator

appsettings.json is the default configuration file for an ASP.NET Core application. When the host starts, it registers this file as a configuration source, so its contents become available through IConfiguration and the strongly typed options pattern. It holds framework settings such as Logging and AllowedHosts, your ConnectionStrings, and any custom sections your application defines.

It is standard JSON: objects, arrays, strings, numbers, booleans, and null, indented with two spaces. JSON does not support comments or trailing commas, so this generator never emits them.

1. Pick a preset (API, SQL Server, JWT, Microservice…) or add individual sections.
2. Edit keys and values inline. Sensitive fields (passwords, keys, secrets) are masked automatically.
3. Watch the appsettings.json output regenerate live on the right, with structural validation.
4. Switch output tabs to get environment variables, Docker, Kubernetes, and C# options classes with registration code.
5. Copy or download any output, or Import JSON to load an existing file into the builder.

A typical Web API configuration looks like this:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=MyDb;User Id=sa;Password=;TrustServerCertificate=True;"
  },
  "Jwt": {
    "Issuer": "https://localhost:5001",
    "Audience": "my-api"
  },
  "Redis": {
    "ConnectionString": "localhost:6379"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*"
}

ConnectionStrings holds named database strings; Jwt and Redis are custom sections your code binds and reads; Logging sets per-namespace log levels; and AllowedHosts is enforced by the Host Filtering middleware.

Connection strings live under the ConnectionStrings object, keyed by name:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=MyDb;..."
  }
}

Read a named string with the dedicated helper:

var connectionString =
    builder.Configuration.GetConnectionString("DefaultConnection");

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString));

Need to assemble the string itself? The Connection String Builder covers SQL Server, PostgreSQL, MySQL, and more.

Store non-secret JWT values in a Jwt section and bind them to an options class. The signing key is a secret — leave it blank in the file and supply it from environment variables or a key vault.

{
  "Jwt": {
    "Key": "",
    "Issuer": "https://localhost:5001",
    "Audience": "my-api",
    "AccessTokenExpirationMinutes": 60
  }
}

Adding this section does not enable authentication. You still call AddAuthentication().AddJwtBearer(...) in code and read these values there. Binding to a class is described under strongly typed configuration.

A Redis section usually stores a connection string and an instance name prefix:

{
  "Redis": {
    "ConnectionString": "localhost:6379",
    "InstanceName": "MyApp:"
  }
}

appsettings only stores these values. You still register the client (for example AddStackExchangeRedisCache or a ConnectionMultiplexer) and pass the connection string in code.

Store broker connection details and read them when building a ConnectionFactory:

{
  "RabbitMQ": {
    "Host": "localhost",
    "Port": 5672,
    "Username": "guest",
    "Password": "guest",
    "VirtualHost": "/"
  }
}

Configuration alone does not open a connection — your code consumes these settings. Do not ship the default guest/guest credentials to production; the built-in guest user can only connect from localhost anyway.

A common pattern is to store allowed origins in configuration and read them when adding a CORS policy:

{
  "Cors": {
    "AllowedOrigins": [ "https://example.com", "https://app.example.com" ],
    "AllowCredentials": true
  }
}

var origins = builder.Configuration
    .GetSection("Cors:AllowedOrigins").Get<string[]>() ?? [];

builder.Services.AddCors(o => o.AddDefaultPolicy(p =>
    p.WithOrigins(origins).AllowAnyHeader().AllowAnyMethod()));

ASP.NET Core does not enable CORS from arbitrary JSON — you wire it up in code. Never combine AllowAnyOrigin with credentials; list trusted origins explicitly. Note that AllowedHosts (host filtering) is a different feature from CORS.

ASP.NET Core reads environment variables as a configuration source that overrides appsettings.json. Hierarchy is expressed with a double underscore (__) because : is not valid in environment-variable names on all platforms:

Jwt:Issuer                         ->  Jwt__Issuer
Jwt:Key                            ->  Jwt__Key
ConnectionStrings:DefaultConnection ->  ConnectionStrings__DefaultConnection

The generator's Environment Variables tab produces this mapping in .env, Bash, PowerShell, Docker Compose, and Kubernetes formats — masking secrets as ${PLACEHOLDER}by default so you don't leak real values.

You can bake appsettings.json into your image, but sensitive values are better injected at runtime as environment variables. In Docker Compose:

services:
  api:
    image: myapp:latest
    environment:
      ASPNETCORE_ENVIRONMENT: Production
      ConnectionStrings__DefaultConnection: ${DATABASE_CONNECTION}
      Jwt__Key: ${JWT_KEY}

Prefer ${VAR} references (resolved from the host or an .env file) for secrets rather than committing them into the compose file.

Split configuration by sensitivity: non-secret values into a ConfigMap, secrets into a Secret, both keyed with __ so they map to configuration hierarchy. Mount them with envFrom.

apiVersion: v1
kind: ConfigMap
metadata:
  name: myapp-config
data:
  Jwt__Issuer: "https://localhost:5001"
  AllowedHosts: "*"

Kubernetes Secrets are only base64-encoded by default. Whether they are encrypted at rest depends on your cluster configuration, so treat the generated manifest as a template and manage real secrets through a secret manager.

Instead of reading magic strings everywhere, bind a section to a class:

public sealed class JwtOptions
{
    public string Key { get; set; } = string.Empty;
    public string Issuer { get; set; } = string.Empty;
    public string Audience { get; set; } = string.Empty;
    public int AccessTokenExpirationMinutes { get; set; }
}

builder.Services.Configure<JwtOptions>(
    builder.Configuration.GetSection("Jwt"));

The C# Code tab generates this class, the registration, and an IOptions usage example from your actual configuration — inferring property types and honoring nullable reference types.

Inject the bound options into your services via IOptions<T>:

public sealed class TokenService
{
    private readonly JwtOptions _options;

    public TokenService(IOptions<JwtOptions> options)
    {
        _options = options.Value;
    }
}

Use IOptionsSnapshot<T> for per-request reloads and IOptionsMonitor<T> for change notifications. To fail fast on invalid configuration, register with AddOptions<T>().Bind(...).ValidateDataAnnotations().ValidateOnStart() — the generator can emit that form too.

ASP.NET Core builds configuration from ordered providers, and later providers override earlier ones. A common order is:

• appsettings.json
• appsettings.{Environment}.json
• User Secrets (Development only)
• Environment variables
• Command-line arguments

So a value in appsettings.jsoncan be overridden by an environment variable at deploy time — ideal for keeping secrets out of the file while sharing non-secret defaults. The exact order can change if the host is customized, so don't assume it blindly.

Environment-specific files layer on top of the base file for the current environment:

appsettings.json               // shared defaults (committed)
appsettings.Development.json    // local overrides (committed, no secrets)
appsettings.Production.json     // production overrides (no secrets)

Keep shared settings in appsettings.json and override only what differs per environment. Do not commit production secrets to any of these files — use environment variables and secret managers instead.

appsettings.json is not a secret store — it is plain text and usually committed. Do not put database passwords, API keys, JWT signing keys, or client secrets in it.

For local development, use User Secrets:

dotnet user-secrets init
dotnet user-secrets set "Jwt:Key" "your-development-secret"

For production, prefer:

• Environment variables
• Azure Key Vault, AWS Secrets Manager, or HashiCorp Vault
• Managed identities (no secret in the string at all)
• Kubernetes Secrets or CI/CD secret stores

User Secrets are a development convenience, not an enterprise production secret manager. And a Kubernetes Secret is not automatically encrypted just because of its name.

• Invalid JSON. Trailing commas or comments — JSON supports neither.
• Wrong environment-variable separator. Using a single _ instead of __ for nested keys.
• Hard-coding secrets. Committing passwords and keys into appsettings.json.
• Assuming JSON configures the framework. A Jwt, Cors, or HealthChecks section does nothing until your code reads it and calls the relevant APIs.
• Confusing AllowedHosts with CORS. They solve different problems.
• Wrong section names. The key in the file must exactly match the section you bind in code.

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

What is appsettings.json?

appsettings.json is the default JSON configuration file for an ASP.NET Core application. At startup the host adds it as a configuration source, so any settings it contains — connection strings, logging levels, feature flags, and your own sections — become available through IConfiguration and the options pattern. It is plain JSON with a 2-space convention and no comments.

What is appsettings.Development.json?

appsettings.Development.json is an environment-specific override loaded on top of appsettings.json when ASPNETCORE_ENVIRONMENT is Development. Values in the environment file replace matching keys from the base file, so you can keep shared settings in appsettings.json and only override what differs per environment (Development, Staging, Production).

How do I create an appsettings.json file?

Add a file named appsettings.json to your project root, set it to copy to the output directory, and add JSON sections such as ConnectionStrings, Logging, and AllowedHosts. This generator builds a valid file for you: pick sections, fill in values, and copy or download the result. New ASP.NET Core project templates already include a starter appsettings.json.

How do I add a connection string to appsettings.json?

Add a "ConnectionStrings" object with a named entry, e.g. { "ConnectionStrings": { "DefaultConnection": "Server=localhost;Database=MyDb;..." } }. The name (DefaultConnection) is how you reference it in code.

How do I read a connection string in ASP.NET Core?

Use builder.Configuration.GetConnectionString("DefaultConnection"), which is shorthand for reading ConnectionStrings:DefaultConnection. Pass the result to your DbContext options (e.g. UseSqlServer(connectionString)) or client library.

How do I store JWT settings in appsettings.json?

Add a "Jwt" section with values like Issuer, Audience, and expiry, and bind it to a strongly typed options class. Keep the signing key out of the file — supply it from environment variables, User Secrets, or a key vault. Adding a Jwt section does not enable authentication by itself; you still configure AddAuthentication().AddJwtBearer(...) in code.

How do I use environment variables with appsettings.json?

ASP.NET Core adds an environment-variable configuration source that overrides appsettings.json. Nested keys use a double underscore: Jwt:Issuer becomes Jwt__Issuer, and ConnectionStrings:DefaultConnection becomes ConnectionStrings__DefaultConnection. This tool converts your configuration to environment variables in .env, Bash, PowerShell, Docker, and Kubernetes formats.

How does ASP.NET Core configuration work?

The host builds configuration from multiple providers in order: appsettings.json, appsettings.{Environment}.json, User Secrets (in Development), environment variables, and command-line arguments. Later providers override earlier ones, so the same key can be set in the file and overridden by an environment variable at deploy time. Your exact order can differ if the host is customized.

How do I convert appsettings.json to environment variables?

Flatten each nested key into a single name joined by double underscores (__) and assign the leaf value. This tool does it automatically and outputs the result for .env files, Bash/PowerShell, Docker Compose, and Kubernetes, masking sensitive values as placeholders by default.

Can I use appsettings.json with Docker?

Yes. You can bake appsettings.json into the image, but sensitive values are better injected as environment variables at runtime. In Docker Compose, set them under a service's environment block using the __ separator, and prefer ${VAR} references (from the host or an .env file) for secrets rather than hard-coding them.

Can I use appsettings.json with Kubernetes?

Yes. Non-sensitive configuration typically goes into a ConfigMap and sensitive values into a Secret, both keyed with the __ separator so they map to configuration hierarchy. Mount them as environment variables via envFrom. Kubernetes Secrets are only base64-encoded by default, so rely on your cluster's encryption-at-rest and access controls for real protection.

How do I create a C# options class from appsettings.json?

Create a class whose properties match the section's keys, then bind it with builder.Services.Configure<JwtOptions>(builder.Configuration.GetSection("Jwt")). This generator infers property types from your values and produces the class, the registration code, and an IOptions usage example.

What is the IOptions pattern?

The options pattern binds a configuration section to a strongly typed class and injects it as IOptions<T>, IOptionsSnapshot<T>, or IOptionsMonitor<T>. It gives you type safety, validation, and testability instead of reading magic strings from IConfiguration throughout your code.

Should passwords be stored in appsettings.json?

No — appsettings.json is usually committed to source control, so it is not a secret store. Keep production passwords, API keys, and signing keys in environment variables, User Secrets (for local development), or a managed secret store such as Azure Key Vault, AWS Secrets Manager, or HashiCorp Vault.

Is appsettings.json secure?

appsettings.json provides no encryption or access control on its own; it is a plain text file. Treat it as non-secret configuration and layer real secret management on top (environment variables and secret managers). A Kubernetes Secret is not automatically encrypted just because it is called a Secret.