Ruby May Finally Fix the Famous “Norway Problem”

July 21, 2026

The Ruby ecosystem may soon take an important step toward modern YAML support. Hiroshi SHIBATA (hsbt), a Ruby core developer, has introduced an experimental backend for the Psych library based on libfyaml, bringing full YAML 1.2 compliance closer to Ruby.

While this might sound like an internal implementation detail, it addresses one of YAML’s longest-standing surprises: the infamous “Norway problem.”

Built for Ruby on Rails

Build Maps Without
Google APIs

Generate beautiful production-ready maps directly from your Rails backend. Fast rendering, zero external dependencies, full control.

View Live Demo → Read Docs

✓ No API fees ✓ Self-hosted ✓ Rails Native ✓ Fast Rendering

Why developers switch

Replace expensive map stacks.

Stop relying on third-party map billing and bloated JS libraries. Render static or dynamic maps directly in Ruby.

Try It Now

What Is the Norway Problem?

For many years, Ruby’s Psych library has relied on libyaml, which implements the YAML 1.1 specification.

Under YAML 1.1, several plain words are automatically interpreted as boolean values:

enabled: yes
disabled: no
power: on
logging: off

When parsed, these become:

{
  "enabled" => true,
  "disabled" => false,
  "power" => true,
  "logging" => false
}

The problem appears when those values are intended to be plain strings.

Consider the following configuration:

country: no

Today, Ruby parses it as:

{
  "country" => false
}

instead of the expected:

{
  "country" => "no"
}

Since NO is the ISO country code for Norway, this behavior became widely known as the Norway problem.

YAML 1.2 Changes the Rules

YAML 1.2 simplified boolean parsing to better align with JSON.

Only the literals:

true
false

are interpreted as booleans.

Values such as:

yes
no
on
off

remain ordinary strings unless explicitly quoted or converted by the application.

This makes YAML documents significantly more predictable and avoids many subtle bugs caused by automatic type conversion.

Psych Meets libfyaml

The proposed change introduces libfyaml as an experimental, opt-in backend for Psych.

The existing architecture looks like this:

Psych
└── libyaml

With the new work, developers will be able to use:

Psych
├── libyaml   (current default)
└── libfyaml  (experimental)

Importantly, this is not a replacement for Psych. Instead, it gives Psych an alternative parser that fully implements the YAML 1.2 specification.

Why This Matters

Although many Ruby developers rarely think about YAML, it is everywhere:

• Rails configuration files
• GitHub Actions workflows
• Docker Compose
• Kubernetes manifests
• RubyGems metadata
• CI/CD pipelines
• Application settings

Using a parser that follows the modern specification improves interoperability with other tools and eliminates surprising parsing behavior that has existed for years.

What About Compatibility?

This is exactly why the feature is experimental and opt-in.

Some applications unknowingly rely on YAML 1.1 semantics. For example:

enabled: yes

currently becomes:

true

Under YAML 1.2, the same value would be parsed as:

"yes"

Applications expecting a boolean could therefore behave differently.

By introducing libfyaml as an optional backend first, the Ruby core team can gather feedback, identify compatibility issues, and evaluate the path toward broader adoption without breaking existing applications.

Looking Ahead

This work does not mean Ruby is switching to YAML 1.2 overnight. Instead, it represents the first step toward modernizing one of Ruby’s foundational libraries.

If the experiment proves successful, future versions of Psych could gradually move the ecosystem toward full YAML 1.2 compliance, bringing Ruby in line with the current specification and eliminating one of YAML’s most notorious historical quirks.

Sometimes the most impactful improvements aren’t new language features—they’re the small infrastructure changes that quietly make software more reliable for everyone.