Java Properties Viewer

Open a Java .properties file and read it as a structured key/value table instead of scanning raw text. The viewer follows the real java.util.Properties rules: keys separated from values by =, :, or whitespace, comments beginning with # or !, logical lines split across physical lines with a trailing backslash, and \uXXXX plus character escapes decoded to real text. Toggle a JSON view when you want to copy the values into another format. Nothing is uploaded: the file is parsed entirely in your browser, so config and secrets stay on your machine.

How to use the Java Properties Viewer

Paste the contents of a .properties file into the box, or load one with the file picker. The viewer parses it on the spot and shows a two-column table of every key and its decoded value, with a count of how many properties were found and how many comment lines were skipped. Use the filter box to keep only the rows whose key or value contains your search text, which is handy for locating one setting inside a large Spring or i18n bundle.

Tick Show as JSON to swap the table for a formatted JSON object with the same keys and values, ready to copy into a converter, a config loader, or a test fixture. Because the parser decodes escapes, a value written as café or with \t tabs appears as the real character in both views. Duplicate keys are resolved the way Properties.load() resolves them: the last definition wins, matching what your application would actually read at runtime.

What is a Java .properties file?

A .properties file is the classic Java configuration format: a flat list of key/value pairs, one logical entry per line. It is read by java.util.Properties and underpins a lot of the JVM ecosystem — application settings, ResourceBundle message catalogs for internationalization (messages_en.properties, messages_fr.properties), Spring Boot's application.properties, logging configuration, and build tooling. The format looks simple, but its parsing rules have several corners that a naive split on = gets wrong.

A key and value can be separated by an equals sign, a colon, or simply whitespace, so db.host=localhost, db.host : localhost, and db.host localhost all mean the same thing. Leading whitespace on a line is ignored, and the first unescaped =, :, or run of spaces ends the key. Lines whose first non-blank character is # or ! are comments. A backslash at the end of a line continues the value onto the next physical line, so long values can wrap. Within values, escape sequences like \n, \t, \\, and \= are interpreted, and \uXXXX denotes a Unicode code point.

That last point is historical: the standard Properties.load(InputStream) reads bytes as ISO-8859-1 (Latin-1), not UTF-8. To store characters outside Latin-1 you traditionally escaped them as \uXXXX, and the JDK shipped a native2ascii tool to do it. Modern code can use Properties.load(Reader) with an explicit UTF-8 reader, and many frameworks now read properties as UTF-8 directly, but the \u convention is still everywhere in older bundles. Compared with YAML, properties files are flat (no native nesting — hierarchy is faked with dotted keys like server.port), have no list or map types, and no significant indentation, which makes them trivial to diff and merge but awkward for deeply structured config.

Common use cases

• Auditing config. Read an application.properties or environment-specific file as a clean table to confirm what a service will load.
• Checking i18n bundles. Decode \uXXXX escapes in a ResourceBundle to see the real translated strings.
• Converting to JSON. Flip to the JSON view to move flat properties into a JSON-based config or a test fixture.
• Spotting duplicates. See which keys are defined more than once and which value actually wins at load time.