When Spring Boot Finds Both application.properties and application.yaml… What Really Happens?

I still remember the first time I dropped both application.properties and application.yaml into the same Spring Boot project. One file came from an old module, another from a teammate who swore YAML was the future.

The result? A quiet but extremely confusing battle for configuration dominance.

Fortunately, this is not the usual case, people mostly choose only one but its good to understand the concept

If you’ve ever wondered which file wins, whether Spring Boot merges them, or if you’re about to break something silently… this story will save you from some real-world debugging pain.

Let’s dive in.

Full story for non-members | Grab My Microservices E-Book | Youtube | LinkedIn | Book a 1:1 Meeting

The Silent Truth: Spring Boot Loads Both Files

Spring Boot isn’t picky. It doesn’t look at your project and say:

“Ah, you’ve picked YAML. Let me ignore the properties file.”

No. It loads both:

• application.properties
• application.yml or application.yaml

Every file gets pulled in, processed, and transformed into a single flattened configuration map.

That means Spring Boot is perfectly comfortable reading key–value pairs side by side, no matter which syntax they came from.

But here’s where things get interesting.

The Real Question: Who Wins When Keys Clash?

Imagine both files define the same configuration:

application.properties

server.port=8080

application.yaml

server:
  port: 9090

You might expect the properties file to win because it appears first alphabetically. Or because properties have been around longer. Or because they “look” more traditional.

But Spring Boot has its own rules.

The winner is YAML.

Why? Because of Spring Boot’s configuration loading order. YAML is loaded after .properties, and in Spring Boot, later sources override earlier ones.

So in the above example, the final server port that your app boots on is 9090.

This surprises almost everyone the first time.

The Order of Loading: The Rules Behind the Magic

Spring Boot loads configuration files using its ConfigData API. In simple terms: files loaded later override keys loaded earlier.

Here’s how Spring Boot loads them:

1. application.properties
2. application.yml
3. application.yaml

It’s not alphabetical. It’s not chronological. It’s simply how Spring Boot’s loader was designed.

Which means, if all three exist, application.yaml has the last say.

Does Spring Boot Merge Configurations? Absolutely.

Consider these two definitions:

application.properties

spring.datasource.url=jdbc:postgresql://localhost/db1

application.yaml

spring:
  datasource:
    username: appuser

Spring Boot will combine them. The datasource URL comes from the .properties file, the username from the YAML file. Both become part of the same configuration key space.

So Spring doesn’t just override blindly. It merges where possible and overrides only when the same key is defined in multiple locations.

This is why many apps continue to work even when developers mix file formats.

The danger lies only in overlapping keys.

When Things Go Wrong: Real-World Pitfalls

Here are a few classic scenarios that catch teams off-guard:

1. Debugging mismatched values

A developer updates application.properties, expecting the app to use that value… But YAML overrides it quietly.

The logs show something else. Cue the head-scratching.

2. Accidental overrides during merges

Two branches use different file formats. Git merges both. One developer never realises YAML wins.

3. Production surprises

Everything works locally using one file format. But in CI/CD pipelines or real servers, an older YAML file lingers and takes precedence.

Silent overrides are the hardest to debug.

The Best Practice: Choose One Format and Stick to It

Spring Boot supports both formats for convenience, but using both at the same time creates invisible complexity.

If your team has:

• junior developers,
• multiple feature branches,
• a CI pipeline,
• production hardening,

then configuration predictability matters far more than file-format loyalty.

YAML is more readable and structured. Properties is more old-school and simple.

Pick one. Stick to it. Avoid future ambiguity.

But What About Profiles?

Profiles follow the same rule.

Spring Boot loads:

• application.properties → then
• application.yml → then
• application.yaml

Then it loads:

• application-dev.properties
• application-dev.yml
• application-dev.yaml

Again, YAML has the last word.

If you mix formats inside profile-specific files, the same override rules apply.

So What Should You Do Today?

Here’s the most practical takeaway: If your project already contains both formats and you’re not sure whether anything overlaps, do a simple search for key names that appear in both places.

Look for:

• server.port
• spring.datasource.*
• logging.level.*
• management.*
• any custom prefixes

Merge everything into one file. Push it. Review it. And delete the other file.

You’ll thank yourself when onboarding new developers or debugging production.

Closing Thoughts

Spring Boot’s flexibility in reading multiple configuration formats is powerful, but it also sets the stage for subtle bugs when both .properties and .yaml coexist.

The core rules are beautifully simple:

• Spring Boot loads everything.
• Later files override earlier ones.
• YAML loads after properties.
• Conflicts go to the last loader.
• Non-conflicting keys are merged.

Once you know this, the mystery disappears, and your configuration becomes predictable, traceable, and clean.

Clean configs mean fewer surprises, fewer production issues, and fewer late-night debugging sessions. And in any engineering team, that’s priceless.

======

More stories like Spring Boot

[embed]Spring Boot Deep Dive | Spring Boot Interview Spring boot concepts from basic to advance topics. Spring Boot based project Ideas to implement. Microservices with…codefarm0.medium.com