YAML to .env / .properties

Flatten nested YAML into flat environment variables or Java properties.

Format:UPPERCASE_KEYS

Input YAML

.env Output

A team writes config in application.yml for local development, then ships the same service into a Docker container that only honors .env. Or a Kubernetes ConfigMap stores nested YAML, but the pod's init script reads flatKEY=value lines. This converter walks your nested YAML, joins keys with an underscore (or any separator you pick), optionally uppercases them, and prints a paste-ready .env or Java .properties file. Anchors and aliases are resolved before flattening so the output matches what the loader will see. Everything runs in your browser; nothing — including database passwords or API keys — is uploaded anywhere.

How to flatten YAML

Paste YAML on the left — Spring Boot application.yml, Kubernetes ConfigMap data, or any nested config block.
Pick the output format: .env for Docker / Node / shell scripts, .properties for JVM applications.
Toggle uppercase keys if the consumer expects shouty DATABASE_URL rather than database_url.
Adjust the separator: underscore is standard for env vars, dot is standard for properties.
Copy the output straight into your .env file, CI secret manager, or Kubernetes Secret YAML.

Example 1: Spring Boot application.yml

Spring Boot accepts both YAML and properties out of the box. Teams that move to SPRING_* environment variables for containerized deploys need every nested key flattened with underscores.

Input YAML

spring:
  datasource:
    url: jdbc:postgresql://db:5432/app
    username: app_user
    password: s3cret
  jpa:
    hibernate:
      ddl-auto: validate
server:
  port: 8080

.env output

SPRING_DATASOURCE_URL=jdbc:postgresql://db:5432/app
SPRING_DATASOURCE_USERNAME=app_user
SPRING_DATASOURCE_PASSWORD=s3cret
SPRING_JPA_HIBERNATE_DDL_AUTO=validate
SERVER_PORT=8080

Example 2: Arrays and multi-line strings

List items become indexed keys. Multi-line block scalars (| for literal, > for folded) keep their newlines as escaped \n sequences so shell parsers can handle them safely.

Input YAML

app:
  allowedOrigins:
    - https://app.example.com
    - https://admin.example.com
  certificate: |
    -----BEGIN CERTIFICATE-----
    MIIBkTCB+w...
    -----END CERTIFICATE-----

.env output

APP_ALLOWEDORIGINS_0=https://app.example.com
APP_ALLOWEDORIGINS_1=https://admin.example.com
APP_CERTIFICATE="-----BEGIN CERTIFICATE-----\nMIIBkTCB+w...\n-----END CERTIFICATE-----\n"

YAML specification reference

Quick reference from YAML 1.2. The converter enforces these rules on input; anything outside them is rejected or normalized.

Element	Meaning	Example
Mapping	Block or flow key/value pairs	name: alice
Sequence	Ordered list with `- ` or flow `[...]`	- apple - banana
Scalar	Plain, single-quoted, double-quoted, literal `\|`, folded `>`	"hello\n"
Anchor / alias	& defines, * references; enables DRY configs	&base *base
Tag	Explicit type: !!int, !!str, !!binary …	!!int "42"

Common invalid forms

name:alice  // missing space after colon
- item
 -indented  // inconsistent indent
flag: yes
	value: 1  // tab used for indent (YAML forbids tabs)

YAML scalar types and how they flatten

YAML	.env line	Note
`port: 8080`	`PORT=8080`	Numbers serialize as-is
`debug: true`	`DEBUG=true`	Booleans become lowercase strings
`password: "p@ss word"`	`PASSWORD="p@ss word"`	Values with spaces or special chars are quoted
`secret: null`	`SECRET=`	Null becomes empty string — distinct from absent
`countryCode: "NO"`	`COUNTRYCODE=NO`	Quote in YAML to avoid the Norway problem on 1.1 consumers

Common pitfalls when flattening to .env

Tabs in YAML. Tabs are not allowed for indentation. The parser error usually reads found character that cannot start any token. Configure your editor to insert spaces for *.yaml files (VS Code: "[yaml]": { "editor.insertSpaces": true, "editor.tabSize": 2 }).
The Norway problem. Unquoted NO, YES, ON, OFF become booleans in YAML 1.1. js-yaml uses YAML 1.2 (booleans only from true/false) — but if the downstream consumer is YAML 1.1 strict, you'll get COUNTRYCODE=false unless you quoted the source.
Arrays in env vars. Indexed keys like SERVERS_0, SERVERS_1 are unconventional outside Spring. Many tools expect a comma-joined string (SERVERS=a,b,c) instead — post-process the output if that's your case.
Special characters in values. Dollar signs in .env trigger shell expansion (PASSWORD=$abc becomes empty). Wrap in single quotes (PASSWORD='$abc') when the file is sourced via source .env rather than loaded by dotenv.
Multi-line strings inside env vars. Newlines inside a single env value break many tools. Long values (TLS certificates, RSA keys) belong in a mounted file, not an env var — even though the conversion produces a valid \n-escaped string.
Anchor / alias expansion. Aliases are resolved into duplicated values before flattening, so DRY YAML produces a larger .env. This is expected —.env has no concept of references.
Comments dropped. YAML comments (#) are stripped at parse time. Critical context belongs in field names or as adjacent string values.

This tool vs CLI alternatives

Tool	Best for	Trade-off
This converter	Quick paste-and-convert; secrets stay local	No streaming; in-memory limit ~10 MB
`yq -o props < in.yaml`	Shell pipelines, scripting, very large files	Requires install; quirks in array handling
Spring Boot `SpringApplication` auto-binding	JVM apps — config is already mapped at runtime	Locks you into the Spring ecosystem
Custom Python script with `yaml.safe_load`	Project-specific flattening rules	Maintenance burden; CI dependency

Common use cases

Containerization — generate Docker / Compose environment: values from existing YAML config without rewriting by hand.
Kubernetes ConfigMaps to env vars — turn the YAML data section into a flat .env for testing the same values locally.
Spring Boot migration — convert application.yml to application.properties when joining a codebase that prefers the older format.
Twelve-factor apps — the 12-factor methodology requires config in env vars; flattening YAML is the cleanest path from a structured spec to that form.
CI/CD secret import — most CI providers (GitHub Actions, GitLab CI, CircleCI) accept .env-style bulk secret files.

Related guides

JSON vs YAML: When to Use What — A Developer's Guide

JSON wins on APIs; YAML wins on configs. Side-by-side syntax, parser behaviour, and where each fits across Kubernetes manifests, REST payloads, and GitHub Actions.

Docker Compose for Beginners: From docker run to YAML

How to translate a pile of docker run commands into a single docker-compose.yml. Service definitions, named networks, volumes, env files, and the override patterns for dev vs prod.

YAML Configuration Files: Syntax, Best Practices, and Common Pitfalls

YAML whitespace is unforgiving and the Norway problem (no:) still bites. Types, anchors, aliases, and the rules that keep Kubernetes manifests, GitHub Actions, and Helm values readable.

Kubernetes Manifest Validation: Catch Errors Before kubectl Apply

The cluster is the most expensive place to discover a YAML typo. Schema validation, server-side dry-run, CRDs, and the apiVersion graveyard.

Frequently Asked Questions

Q: How are nested keys flattened?

Each level of nesting is joined with the separator you pick (underscore by default). A YAML key path database.connection.host becomes DATABASE_CONNECTION_HOST with uppercase enabled, or database_connection_host without it. For Java properties, switch the separator to . so the output reads database.connection.host.

Q: How are arrays handled?

List items become indexed keys: SERVERS_0, SERVERS_1, SERVERS_2. Spring Boot reads this convention natively. Other consumers prefer comma-joined values; for that shape, post-process the output in your shell or CI script (echo "SERVERS=$(echo $SERVERS_0,$SERVERS_1)").

Q: What happens with multi-line YAML strings?

Multi-line block scalars (| for literal, > for folded) become quoted strings with escaped newlines (\n) so shell parsers don't choke. For values longer than a few lines (TLS certificates, RSA private keys), consider mounting a separate file rather than packing them into an env var.

Q: Are sensitive values in my YAML uploaded anywhere?

No. The conversion runs entirely in your browser using JavaScript. Database passwords, API keys, JWT secrets — none of it leaves your machine. You can verify by opening DevTools and watching the Network tab while converting. The page makes no outbound requests for the conversion itself.

Q: Can I convert `.env` back to YAML?

Not directly with this tool — flattening is one-way because env keys lose the structural information of the original YAML. If you need YAML back, group keys by common prefix manually first, or maintain the YAML as the source of truth and treat the .env as a derived artifact regenerated by this tool whenever the YAML changes.

Q: How does this handle YAML anchors and aliases?

&name / *name references are resolved during parsing, so the flattened output contains the actual values five times if you had five aliases. Environment variables have no concept of references, so this is the only round-trip-safe option. If keeping the DRY structure matters, generate the .env with this tool each time the YAML changes rather than editing both.

Related Tools

YAML to JSON Converter

Convert YAML data to JSON format with proper structure and data types.

YAML Converter

Convert YAML to CSV, XML, SQL, or Markdown in one unified tool.

YAML Validator

Validate YAML syntax with error reporting and parsed JSON view.

YAML to .env / .properties

Flatten nested YAML into flat environment variables or Java properties.

Format:UPPERCASE_KEYS

Input YAML

.env Output

How to flatten YAML

Paste YAML on the left — Spring Boot application.yml, Kubernetes ConfigMap data, or any nested config block.
Pick the output format: .env for Docker / Node / shell scripts, .properties for JVM applications.
Toggle uppercase keys if the consumer expects shouty DATABASE_URL rather than database_url.
Adjust the separator: underscore is standard for env vars, dot is standard for properties.
Copy the output straight into your .env file, CI secret manager, or Kubernetes Secret YAML.

Example 1: Spring Boot application.yml

Spring Boot accepts both YAML and properties out of the box. Teams that move to SPRING_* environment variables for containerized deploys need every nested key flattened with underscores.

Input YAML

spring:
  datasource:
    url: jdbc:postgresql://db:5432/app
    username: app_user
    password: s3cret
  jpa:
    hibernate:
      ddl-auto: validate
server:
  port: 8080

.env output

SPRING_DATASOURCE_URL=jdbc:postgresql://db:5432/app
SPRING_DATASOURCE_USERNAME=app_user
SPRING_DATASOURCE_PASSWORD=s3cret
SPRING_JPA_HIBERNATE_DDL_AUTO=validate
SERVER_PORT=8080

Example 2: Arrays and multi-line strings

List items become indexed keys. Multi-line block scalars (| for literal, > for folded) keep their newlines as escaped \n sequences so shell parsers can handle them safely.

Input YAML

app:
  allowedOrigins:
    - https://app.example.com
    - https://admin.example.com
  certificate: |
    -----BEGIN CERTIFICATE-----
    MIIBkTCB+w...
    -----END CERTIFICATE-----

.env output

APP_ALLOWEDORIGINS_0=https://app.example.com
APP_ALLOWEDORIGINS_1=https://admin.example.com
APP_CERTIFICATE="-----BEGIN CERTIFICATE-----\nMIIBkTCB+w...\n-----END CERTIFICATE-----\n"

YAML specification reference

Quick reference from YAML 1.2. The converter enforces these rules on input; anything outside them is rejected or normalized.

Element	Meaning	Example
Mapping	Block or flow key/value pairs	name: alice
Sequence	Ordered list with `- ` or flow `[...]`	- apple - banana
Scalar	Plain, single-quoted, double-quoted, literal `\|`, folded `>`	"hello\n"
Anchor / alias	& defines, * references; enables DRY configs	&base *base
Tag	Explicit type: !!int, !!str, !!binary …	!!int "42"

Common invalid forms

name:alice  // missing space after colon
- item
 -indented  // inconsistent indent
flag: yes
	value: 1  // tab used for indent (YAML forbids tabs)

YAML scalar types and how they flatten

YAML	.env line	Note
`port: 8080`	`PORT=8080`	Numbers serialize as-is
`debug: true`	`DEBUG=true`	Booleans become lowercase strings
`password: "p@ss word"`	`PASSWORD="p@ss word"`	Values with spaces or special chars are quoted
`secret: null`	`SECRET=`	Null becomes empty string — distinct from absent
`countryCode: "NO"`	`COUNTRYCODE=NO`	Quote in YAML to avoid the Norway problem on 1.1 consumers

Common pitfalls when flattening to .env

Tabs in YAML. Tabs are not allowed for indentation. The parser error usually reads found character that cannot start any token. Configure your editor to insert spaces for *.yaml files (VS Code: "[yaml]": { "editor.insertSpaces": true, "editor.tabSize": 2 }).
The Norway problem. Unquoted NO, YES, ON, OFF become booleans in YAML 1.1. js-yaml uses YAML 1.2 (booleans only from true/false) — but if the downstream consumer is YAML 1.1 strict, you'll get COUNTRYCODE=false unless you quoted the source.
Arrays in env vars. Indexed keys like SERVERS_0, SERVERS_1 are unconventional outside Spring. Many tools expect a comma-joined string (SERVERS=a,b,c) instead — post-process the output if that's your case.
Special characters in values. Dollar signs in .env trigger shell expansion (PASSWORD=$abc becomes empty). Wrap in single quotes (PASSWORD='$abc') when the file is sourced via source .env rather than loaded by dotenv.
Multi-line strings inside env vars. Newlines inside a single env value break many tools. Long values (TLS certificates, RSA keys) belong in a mounted file, not an env var — even though the conversion produces a valid \n-escaped string.
Anchor / alias expansion. Aliases are resolved into duplicated values before flattening, so DRY YAML produces a larger .env. This is expected —.env has no concept of references.
Comments dropped. YAML comments (#) are stripped at parse time. Critical context belongs in field names or as adjacent string values.

This tool vs CLI alternatives

Tool	Best for	Trade-off
This converter	Quick paste-and-convert; secrets stay local	No streaming; in-memory limit ~10 MB
`yq -o props < in.yaml`	Shell pipelines, scripting, very large files	Requires install; quirks in array handling
Spring Boot `SpringApplication` auto-binding	JVM apps — config is already mapped at runtime	Locks you into the Spring ecosystem
Custom Python script with `yaml.safe_load`	Project-specific flattening rules	Maintenance burden; CI dependency

Common use cases

Containerization — generate Docker / Compose environment: values from existing YAML config without rewriting by hand.
Kubernetes ConfigMaps to env vars — turn the YAML data section into a flat .env for testing the same values locally.
Spring Boot migration — convert application.yml to application.properties when joining a codebase that prefers the older format.
Twelve-factor apps — the 12-factor methodology requires config in env vars; flattening YAML is the cleanest path from a structured spec to that form.
CI/CD secret import — most CI providers (GitHub Actions, GitLab CI, CircleCI) accept .env-style bulk secret files.