YINI is an INI-inspired, indentation-insensitive configuration format with clear nested sections, explicit structure, and predictable parsing.

It is designed for configuration files that should be easy to read, easy to write, and straightforward for parsers and tools to process.

In simple terms: YINI is a file format for storing application settings, similar in purpose to INI, JSON, YAML, or TOML configuration files. It is meant for settings such as app names, ports, feature flags, paths, database options, and tool configuration — but with a syntax that aims to stay readable, explicit, and predictable.

@yini

^ Application
name = 'Demo Application'
version = '1.0.0'
debug = yes

^^ Server
host = 'localhost'
port = 8080

^^^ Logging
level = 'info'
file = './app.log'

This represents the same kind of configuration data as this JSON:

{
    "Application": {
        "name": "Demo Application",
        "version": "1.0.0",
        "debug": true,
        "Server": {
            "host": "localhost",
            "port": 8080,
            "Logging": {
                "level": "info",
                "file": "./app.log"
            }
        }
    }
}

Or this YAML:

Application:
    name: Demo Application
    version: "1.0.0"
    debug: true
    Server:
        host: localhost
        port: 8080
        Logging:
            level: info
            file: ./app.log

Or this TOML:

[Application]
name = "Demo Application"
version = "1.0.0"
debug = true

[Application.Server]
host = "localhost"
port = 8080

[Application.Server.Logging]
level = "info"
file = "./app.log"

The YINI specification is currently in release candidate state. The core parser implementations are being validated against a shared test suite before the first stable 1.0.0 release.

Feedback, bug reports, parser comparisons, and careful review are very welcome.

YINI focuses on:

• Clear and readable configuration files — with key = value assignments, similar to classic INI files.
• Explicit nested sections — with repeated section markers, similar in spirit to Markdown headings.
• Indentation-insensitive structure — indentation is optional and may be used for readability, but does not define nesting.
• Predictable parsing rules — the same input should produce the same structure across implementations.
• Minimal syntax surprises — YINI prefers explicit rules over implicit rules or magic.
• Human-friendly and parser-friendly structure — files should be readable for people and straightforward for tools to process.
• Practical use in real applications and tools — YINI is intended for application settings, CLI tools, service configuration, and project metadata.

YINI is not intended to be clever or magical. The goal is a small, understandable configuration format with enough structure for serious use.

• YINI-spec — the YINI language specification and grammar.
• yini-parser-typescript — official Node.js / TypeScript parser implementation.
• yini-parser-python — official Python parser implementation.
• yini-cli — command-line tooling for validating and working with YINI files.
• yini-demo-apps — small demo applications showing how YINI can be used in real projects.
• syntax-highlighting — syntax highlighting definitions for editors that support TextMate grammars.
• yini-homepage — homepage and documentation site for YINI.

The shared parser test suite, yini-test, is currently private while it is being prepared for public use.

The easiest way to understand YINI is to look at a small configuration file and parse it with one of the available tools.

You can try YINI through:

• The TypeScript / Node.js parser.
• The Python parser.
• The command-line tool.
• Small demo apps using YINI.
• Third-party and other YINI tools.
• Or jump to the Getting Started guide on the YINI website.

Documentation and examples are available at:

yini-lang.org

Contributions are welcome, especially:

• Specification feedback.
• Parser bug reports.
• Test cases.
• Documentation improvements.
• Examples and integrations.
• Review of edge cases before 1.0.0.

If you notice something unclear, surprising, inconsistent, or difficult to implement, please open an issue or discussion.

YINI is a young project, so early feedback and real-world testing are especially valuable.

YINI is built around a simple idea:

Configuration should be clear to humans and predictable for tools.

The format favors explicit structure over hidden behavior, readability over cleverness, and consistency over shortcuts.

Released under MIT or Apache License 2.0 depending on the exact repository.

^YINI ≡

A clear, structured, human-friendly configuration format.

yini-lang.org