Introduction

When a Docker push to a private Amazon ECR repository fails with a "malformed JSON" style error, the problem is rarely the image layers themselves. It is usually in the authentication or tooling path: outdated AWS CLI usage, shell quoting problems, stale Docker credentials, wrong registry URI, or a proxy or credential helper returning something Docker cannot parse cleanly.

Start with the Correct Login Flow

The reliable modern login command is:

aws ecr get-login-password --region us-east-1 | \
docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com

Then tag and push:

docker tag my-image:latest 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-repo:latest
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-repo:latest

If you are still using older aws ecr get-login patterns, switch first. A lot of confusing JSON-related failures come from outdated login commands or shell-evaluated login strings that break on quoting.

Why the Error Often Looks Unrelated

ECR push problems can surface as a malformed JSON message because multiple tools are involved:

• AWS CLI retrieves an authorization token
• Docker stores or uses credentials
• the Docker client talks to the ECR registry endpoint

If one tool emits unexpected text, truncates output, or uses stale credentials, the visible error can look like a parsing problem instead of a straightforward authentication problem.

That is why the right debugging approach is to validate the entire chain, not just the final docker push.

Verify the Registry URI

The repository URI must match:

• the correct AWS account
• the correct region
• the correct repository name

Example:

123456789012.dkr.ecr.us-east-1.amazonaws.com/my-repo

A region mismatch is a classic mistake. Logging into us-east-1 and pushing to a registry URI in another region will fail in ways that are not always obvious.

Clear Stale Docker Credentials

Docker may have old ECR credentials cached in ~/.docker/config.json. If the stored auth entry is stale or malformed, new logins may not behave the way you expect.

Inspect the config:

cat ~/.docker/config.json

Then re-run the login flow. If necessary, log out first:

docker logout 123456789012.dkr.ecr.us-east-1.amazonaws.com

This is especially useful on shared machines, CI runners, or developer laptops that have switched AWS accounts.

Check AWS Identity and Permissions

Before blaming Docker, confirm the AWS caller identity:

aws sts get-caller-identity

And confirm the repository exists in the expected account and region:

aws ecr describe-repositories --repository-names my-repo --region us-east-1

The principal also needs the relevant ECR permissions for authentication and image upload. If identity and repository look wrong, the JSON error is just a side effect of a deeper configuration mismatch.

CI and Shell Quoting Problems

The older get-login command used to output a full docker login ... command as text. In CI systems or shells with quoting quirks, that output could be mangled before execution.

That is one reason the get-login-password | docker login --password-stdin pattern is better:

• no shell-evaluated password string
• fewer quoting problems
• cleaner logs

If the error only occurs in CI, compare the exact login and tag commands with what works locally.

Proxy and Credential Helper Interference

Docker credential helpers and corporate proxies can also break the auth flow. If the environment injects custom helpers or rewrites traffic, Docker may receive a response it cannot interpret properly.

That is harder to diagnose, but common signs include:

• the same commands work on another machine
• the AWS CLI works but Docker login or push fails
• the error changes when the Docker config file is simplified

In that case, inspect ~/.docker/config.json for credsStore or helper-specific entries and confirm whether the environment adds proxy settings.

Common Pitfalls

• Using the old aws ecr get-login flow instead of the current get-login-password plus --password-stdin approach.
• Logging into one region and pushing to a repository URI in another region.
• Tagging the image with the wrong repository URI or AWS account id.
• Ignoring stale Docker auth entries in ~/.docker/config.json and assuming a fresh AWS login automatically overrides everything.
• Debugging only Docker while never verifying the AWS identity, repository existence, or ECR permissions.

Summary

• Most ECR malformed-JSON push failures are really authentication or configuration problems, not broken image layers.
• Use aws ecr get-login-password | docker login --password-stdin as the baseline login flow.
• Verify region, account id, repository URI, and local Docker credential state.
• Confirm the active AWS identity and repository existence before retrying the push.
• If the issue appears only in CI or one machine, check shell quoting, proxies, and Docker credential helpers.