The Java properties file is a simple, line-oriented configuration format read and written by the java.util.Properties class. The official Oracle documentation describes Properties as “a persistent set of properties” where “each key and its corresponding value in the property list is a string.” Files conventionally use the “.properties” extension and consist of key/value pairs, one per logical line, making them a staple for application settings, internationalization message bundles, and build configuration across the Java ecosystem.
The format’s parsing rules are precisely specified, which is what distinguishes it from the informal INI family. According to the documentation, blank lines are ignored and a line whose first non-whitespace character is ”#” or ”!” is a comment. A key/value pair separates the key from the value with ”=”, ”:”, or whitespace; the key runs from the first non-whitespace character up to the first unescaped separator, and the remainder of the line is the value, which may be empty.
A defining feature is line continuation through backslash escaping. A logical line can span several natural lines when each is ended with a backslash, in which case the line terminator and any leading whitespace on the following line are discarded rather than replaced with a space. The documentation notes that an odd number of trailing backslashes continues the line while an even number encodes literal backslashes, a detail that trips up hand-written files.
Escaping rules borrow from Java string literals but with deliberate differences. The format recognizes “\t”, “\n”, “\r”, ”\”, and “\uXXXX” Unicode escapes, and allows separator and comment characters to be made literal with a backslash, as in ”:” or ”=”. Unlike Java strings, it does not recognize octal escapes, treats “\b” as a literal “b”, and silently drops a backslash before any other character. These rules give the format unambiguous handling of special characters at the cost of some surprising edge cases.
Encoding is the format’s most famous historical wrinkle. The byte-stream load and store methods use ISO-8859-1 (Latin-1) encoding, so any character outside Latin-1, including most accented and non-Western text, must be written as a “\uXXXX” escape. This meant developers traditionally ran the native2ascii tool to convert UTF-8 source into escaped property files. Newer character-stream methods that accept a Reader or Writer, together with an XML-based properties format that defaults to UTF-8, relieved much of that burden.
In the broader landscape of configuration formats, the properties file occupies the same niche as the INI file but with a written specification and rigorous escaping. It is flatter than TOML or YAML, offering no native nesting or rich types, only flat string keys and values, yet that simplicity, combined with deep integration into the Java platform and frameworks like Spring, has kept it in continuous use for decades.