Unquoted special characters are the most common cause of YAML parse errors and wrong values.
YAML has three flow scalar styles:
- Plain (unquoted): the most readable, no escapes, type is inferred.
- Single-quoted
'...': always a string, no escape sequences at all. A single quote inside is written twice:'it''s'. Backslashes are literal, which makes single quotes ideal for regexes and Windows paths. - Double-quoted
"...": always a string, with backslash escapes:\n,\t,\",\\,\u00e9,\x41. The only style that can represent any character, including control characters.
Quote a string when it:
- would be read as another type:
"yes","1.0","null","0123","2026-10-17"; - starts with an indicator:
*,&,!,|,>,%,@, a backtick,[,{,-followed by a space,?or:followed by a space, or a quote; - contains
:(colon space) or#(space hash); - has leading or trailing spaces you want to keep.
A practical rule: prefer plain style for ordinary words, single quotes when something needs quoting, and double quotes only when you need an escape like \n.
Plain scalars can contain : and # when they aren't followed or preceded by a space: http://example.com#top is fine unquoted.
Example
plain: hello world
url: http://example.com/a#frag # fine: no ": " and no " #"
title: 'Note: read this' # must quote, contains ": "
comment: 'a # b' # unquoted, " #" would start a comment
pattern: '^\d+\.\d+$' # single quotes: backslashes are literal
path: 'C:\Users\ana'
its: 'it''s' # -> it's
escaped: "tab\there\nnew line" # double quotes: escapes processed
unicode: "caf\u00e9" # -> café
alias_like: '*not-an-alias'
answer: 'yes' # string, not a YAML 1.1 booleanRemember
- Single quotes: no escapes, '' for a quote; double quotes: backslash escapes
- Quote values containing ': ' or ' #', or starting with * & ! | > % @ [ {
- Quote values that look like numbers, booleans, null or dates
Watch out for
- Writing a regex like \d+ in double quotes, where \d is an invalid escape and fails to parse.