Parsers are not easy to get right. , the reference parser for , does most things right. However, there’s one little thing that it does wrong but since it does everything else sooo right, this little thing has been ignored. Even worse, other parser implementations have been doing it knowingly wrong because “that’s how does it”. There is hope though, keep reading. libyaml YAML libyaml Found unexpected ‘:’ If you’re YAML — and chances are you are one way or another —, you may have stumbled upon this error while parsing things like: parsing urls: [ ] https://medium.com (i.e. flow sequences) or: location: {url: } https://medium.com (i.e. flow mappings) even though the YAML specs say it’s valid: explicitly Normally, YAML insists the be separated from the value by white space. A benefit of this restriction is that the “ ” character can be used inside plain scalars, as long as it is not followed by white space. This allows for unquoted URLs and timestamps. “ **_:_** ” mapping value indicator **:** What’s happening? This is because your YAML parser for <insert_your_language_here> either relies on (loading it as shared library and providing bindings to it) or used as their reference parser, in other words as the “mother of all YAML parsers” and mirrored its behavior rather than following the YAML specs, strictly. Nothing extremely wrong about that but I am relaying the facts. libyaml libyaml The is that there is an easy fix. Quoting a string that contains a colon in a flow context will do (i.e. ). good news 'https://medium.com' The is that it seems like parsers across languages are inconsistently handling this: bad news Python throws an error, a fixes this and has been merged but hasn’t been released yet pyyaml PR Ruby throws an error psych Golang throws an error, issue submitted go-yaml here Java throws an error, issue submitted snakeyaml here JavaScript handles this properly JS-YAML and: throws an error, but the is that there is a that addresses it libyaml other good news PR To sum-up, the only parser that handles this properly as of now is the JavaScript one. The problem with is that if your stack consists of JavaScript and any other language, and that you’re parsing YAML across the board, it may lead to inconsistent parsing behaviors, and that’s not great.