STXT

Built for humans. Reliable for machines.

Start the tutorial Open the playground Tools

STXT: Introduction

STXT is a Human-First markup language, where documents are readable and expressive, and at the same time reliable for machines.

STXT is pronounced "ESS-text" — first the letter S, then text, like S-TEXT.

Documents

STXT is a human-readable markup language for structured documents and data: no braces, no closing tags, no escape characters — just names, values and indentation. It is aimed at:

  • Representing documents and data clearly.
  • Being simple to read and write.
  • Being trivial to parse in any programming language.
  • Allowing both structured content and free text.
  • Applying content rules via @stxt.schema or @stxt.template.

An STXT document combines readability with an explicit semantic structure, which makes it suitable for corporate documents, CMS content and configuration files:

# A simple email, no validation
Email:
	From: John Smith
	To: Mery Adams
	Cc: Keyla Brown
	Title: Project report
	# The body is a literal text block
	Body Content >>
		Hello Mery!
		The book is finished!

The language has few rules, and the example above already uses two. Indentation is the structure: one tab or four spaces per level, and the hierarchy on screen is the hierarchy of the document. Free text is literal: everything indented under a >> node is text exactly as written, with no escapes and no quotes. The tutorial covers the rest in fifteen short sections.

Documents with namespace and schemas

STXT allows the use of namespaces to group documents. Schemas or templates can also be defined to validate the content of a document.

An Email document from the com.example.docs namespace:

Email (com.example.docs):
	From: John Smith <[email protected]>
	To: Mery Adams <[email protected]>
	Cc: Keyla Brown <[email protected]>
	Title: Project report
	Body Content >>
		Hello Mery!!
		The book is finished!!

And the template that validates that namespace:

Template (@stxt.template): com.example.docs
	Structure >>
		Email (com.example.docs):
			From: EMAIL
			To: EMAIL
			Cc: EMAIL
			Bcc: EMAIL
			Title: (?)
			Body Content: (1) TEXT
			Metadata (org.example.meta): (?)

Validation is optional and belongs to the language itself: the template above is STXT too. A validating tool checks that every node is declared, that cardinalities hold and that typed values — dates, numbers, email addresses — are well formed; the closed content model rejects a misspelled field instead of accepting it silently. How documents, definitions and tools fit together in a project is described in The working environment.

How it compares

The comparison with each format has its own page, with the same content written in both:

  • YAML also expresses hierarchy with indentation. It differs underneath: the spelling of a value decides its type, the same structure admits several syntaxes, and there are no namespaces or schemas.
  • JSON is a serialization format, with no comments or multi-line text, and the one STXT adopts as the representation of its tree.
  • XML is the closest: a named tree, namespaces and schemas. The price is closing tags, escapes and entities.
  • TOML shares the goal but not the model: tables of keys with typed values, with the hierarchy in the headers.
  • Markdown formats prose and has no fields; STXT adopts it, with the MARKDOWN type, for the prose of its nodes.

The short version of all five is in the FAQ, and the reasoning behind the design is in Design principles.

Where to start

The language is stable: the syntax and the canonical tree are in Zenith status, and a document valid today stays valid forever. The exact promise is spelled out in Stability and versions, and the FAQ answers the rest.