Clean up and format Java .properties content into a consistent, readable PROPERTIES output—processed locally in your browser.
.properties content into the Input panel — an application.properties, a log4j.properties, a messages_en.properties resource bundle, or any key=value config. The parser accepts UTF-8 input and handles all four legal separators (=, :, space, tab) plus comment lines starting with # or !.ENV, Kubernetes ConfigMap entries) without losing key/value semantics.= (most common in Spring Boot and log4j), : (often seen in older Java EE configs), or space for the rare Hadoop/Ant style. Optional toggles let you add a single space around the separator (key = value) or keep it tight (key=value)..properties file. Everything runs in your browser session — no upload, no signup, no telemetry. Inline error messages flag unterminated unicode escapes (\uXXX with fewer than four hex digits), invalid escape sequences, and broken line continuations with the offending line number.Java .properties is the original configuration format for JVM applications — it's been around since JDK 1.0 (1996) and is still the default for application.properties in Spring Boot, log4j/Logback config, and ResourceBundle localisation files (messages_en.properties, messages_fr.properties). The format looks simple — one key=value per line — but it has surprising rules around escapes, separators, line continuation, and whitespace that trip up everyone eventually. A clean, normalised file makes code review easier, cuts noisy diffs, and surfaces typos the JVM would silently swallow.
application.properties for Spring Boot — Spring Boot reads application.properties (and profile variants like application-prod.properties) from the classpath, config/ directory, or external locations defined via --spring.config.location. A formatted file with consistent = vs = and grouped sections (spring.datasource.*, logging.level.*, management.endpoints.*) keeps the file scannable as it grows past a hundred keys.\uXXXX unicode escapes need exactly four hex digits; one fewer and the parser throws IllegalArgumentException at startup. A typo like caf\u00g9 only surfaces when the JVM loads the bundle. Pasting the file here flags malformed escapes before deployment.messages_*.properties files often round-trip through translation tools that randomise separator style and re-order keys. Formatting puts every file back into a canonical shape so git diff between locales shows only real translation changes.log4j.logger.org.springframework=WARN, logging.level.com.acme=DEBUG) accumulates fast. A pass through the formatter removes trailing whitespace, collapses duplicate blank lines, and aligns continuation lines so the file is readable when you're SSH'd into a production box at 2 AM..properties file rarely fails the build — Spring Boot just silently misses the key and your app starts with a default. Validating the syntax up front catches stray smart quotes, BOM characters, mismatched line continuations, and embedded tabs that confuse the parser..properties (or the reverse) to escape indentation bugs or hierarchy explosions, paste the converted output here to verify it still parses. For straight conversions see YAML to JSON and JSON to YAML — .properties interconverts cleanly with flat JSON.The rules below come straight from Oracle's java.util.Properties.load() documentation — every JVM parser implements these.
| Construct | Example | Notes |
|---|---|---|
Key-value with = |
db.host=localhost |
Most common style; default in Spring Boot |
Key-value with : |
db.host:localhost |
Legacy/Java EE style; still valid |
| Key-value with whitespace | db.host localhost |
First unescaped space/tab/=/: ends the key |
Comment (#) |
# database settings |
Must be first non-blank char on the line |
Comment (!) |
! deprecated key below |
Alternative comment marker; identical semantics |
| Blank line | (empty or whitespace-only) | Ignored by the parser |
| Line continuation | fruits = apple, \ banana, cherry |
Trailing \ continues to next line; leading whitespace on the continuation is stripped |
| Escape: tab/newline/CR | \t \n \r |
Like Java string literals |
| Escape: backslash | path=C:\\Users\\me |
Double backslash for a literal \ |
| Escape: separator in key | key\=with\=equals=value |
Escape =, :, space, #, ! in keys |
| Escape: leading space in value | value=\ leading space kept |
Bare leading spaces in values are stripped unless escaped |
| Unicode escape | greeting=café |
Exactly four hex digits; only one u allowed |
| Trailing whitespace in value | key=value␣␣ (preserved) |
Trailing spaces in values are kept (not trimmed) |
| Empty value | key= or just key |
Both legal; value is the empty string |
Spring Boot ships first-class loaders for .properties and YAML; HOCON and TOML need an external PropertySourceLoader. The table below summarises when to reach for each.
| Property | .properties | YAML (.yml) | HOCON (.conf) | TOML (.toml) |
|---|---|---|---|---|
| Native data types | String only (caller parses) | String, int, float, bool, null, list, map | Same as YAML plus substitutions and includes | String (4 variants), int, float, bool, datetime, array, table |
| Hierarchy | Flat — emulate with dotted keys (spring.datasource.url) |
True nested mappings via indentation | True nested via braces or indent | True nested via [table] headers |
| List / array support | None native; use comma-CSV or key[0], key[1] |
First-class - item sequences |
First-class [ ... ] arrays plus += append |
First-class [ ... ] arrays and [[arrays of tables]] |
| Comments | # or ! at line start |
# line comments |
# and // line comments, /* */ block |
# line comments |
| Indentation sensitivity | None | Significant — wrong indent breaks parsing | None | None |
| Spring Boot support | Built-in, default | Built-in since 1.0 | Third-party (e.g. spring-hocon-property-source) |
No built-in loader; community libs only |
| Profile syntax | application-prod.properties separate file |
Same, plus --- document separator inside one file |
include "prod.conf" directives |
Separate files only |
| Substitution / includes | None — relies on Spring's ${var} resolver |
None native — Spring resolves ${var} placeholders |
Native ${var} and include |
None |
| Best fit | Legacy compatibility, flat configs, log4j, i18n bundles | Multi-profile and nested configs, K8s/CI tooling parity | Akka/Play apps needing includes and overrides | Rust/Python tooling; less common on JVM |
Two main reasons. First, .properties is bulletproof against whitespace bugs — there's no indentation hierarchy, so you can't break the config by hitting Tab instead of Space. Second, flat configurations stay shorter in .properties than YAML. A single key like spring.datasource.hikari.maximum-pool-size=20 is one line; the YAML equivalent costs four indented lines for one value. For Spring Boot apps with mostly flat config, log4j configs, or simple i18n bundles, .properties is genuinely the right tool. YAML wins when you have deeply nested structure (Kubernetes manifests, multi-service compose files) or when you need lists and maps as first-class values.
\uXXXX escapes for non-ASCII characters?Not in most modern setups. Before Java 9 the default encoding for .properties resource bundles was ISO-8859-1, so any character outside Latin-1 had to be escaped as \uXXXX (a process called "native2ascii"). Since Java 9 (per JEP 226) the default for property resource bundles is UTF-8, with automatic fallback to ISO-8859-1 if invalid UTF-8 is detected. For Spring Boot application.properties the default encoding has been UTF-8 since Spring Boot 2.x. So if your app runs on Java 9+ and your editor saves UTF-8, you can write greeting=café directly — no é needed. The escape form is still useful when a downstream tool (older translation systems, legacy build pipelines, SCMs that mangle encoding) might re-interpret the bytes.
Yes. Per the Properties.load() spec, trailing whitespace in values is kept verbatim — key=hello reads back as "hello " with three trailing spaces. Leading whitespace in values is stripped unless you escape the first space as \ . This is the opposite of YAML, which trims trailing whitespace by default. If you've ever had a .properties file where a value behaves differently than it looks in your editor, trailing whitespace is the first thing to check.
End the line with a single backslash \ to continue the value onto the next line. The backslash, the line terminator, and all leading whitespace on the continuation line are discarded by the parser. Example:
fruits=apple, banana, \
cherry, grape, \
kiwi
reads as "apple, banana, cherry, grape, kiwi". Two important quirks: (1) the backslash must be the very last character on the line — a trailing space after it breaks the continuation, and (2) an even number of trailing backslashes means the last one is escaped, so no continuation. If you need a literal newline inside a value, use \n instead of line continuation.
application.properties vs application.yml?Both are loaded identically by Spring Boot's ConfigFileApplicationListener/ConfigDataLocationResolver — same precedence, same profile rules, same ${var} resolution. If both exist in the same location, .properties wins (it's loaded last and overrides). Pick .properties when your config is mostly flat (few nesting levels), when your team is more comfortable with key=value, or when you need to override a single value via an environment variable (SPRING_DATASOURCE_URL maps to spring.datasource.url in either format, but .properties keys are easier to talk about). Pick application.yml when you have deeply nested config, want list/array values written naturally, or want multiple profiles in one file using --- document separators.
Java's Properties.load() is line-ending agnostic — it accepts \n, \r\n, and even bare \r (Mac classic) as line terminators. So your app won't care. Where line endings matter is in version control: a mixed-line-ending file produces noisy diffs every time someone edits it on a different OS. The convention in JVM ecosystems is LF (\n) — .gitattributes typically has *.properties text eol=lf to normalise on commit. CRLF is fine if you're targeting a Windows-only deployment and the whole team uses CRLF locally.
No. The # and ! comment characters are only recognised when they're the first non-blank character on a line. Writing db.host=localhost # primary will store the value as localhost # primary — the # becomes part of the string. This is different from YAML, TOML, HCL, and most modern formats, and it's a frequent source of "why doesn't my config work?" bugs. Always put comments on their own line above the key they describe.
The .properties format defines no uniqueness constraint — if you write the same key twice, the later value wins (last-write-wins per Properties.load() semantics, which is a Hashtable under the hood). This is silent: no warning, no error. The formatter on this page flags duplicate keys so you can dedupe before they bite you in production. If you genuinely need multi-value entries, simulate with indexed keys (smtp.host[0], smtp.host[1]) or comma-separated values — Spring's @Value("${smtp.hosts}") handles both forms.
No. The .properties Formatter runs entirely in your browser session — your config never leaves the tab. There are no network requests after the initial page load, so secrets in spring.datasource.password, API tokens, JWT signing keys, and any other sensitive values stay on your machine. The page also works offline once it's loaded. For pretty-printing related formats see the JSON Formatter for JSON payloads in the same project.