How to fix Error: Extraneous JSON object property in Terraform
This error occurs when using Terraform JSON configuration files (.tf.json) with property names that don't match valid arguments or block types for the resource or block being configured. The error indicates an unrecognized attribute.
Quick fix
Fixes Error: Extraneous JSON object property
{
"resource": {
"aws_instance": {
"example": {
"instance_label": "my-server"
}
}
}
}- Read the error message carefully
- Check the provider documentation
- Fix the property name
- Verify the property exists for your resource type
{"resource": {"aws_instance": {"example": {"instance_label": "my-server"}}}}Error: Extraneous JSON object property
What this error means
Terraform validates JSON configuration files (.tf.json) against a schema of valid arguments and block types for each resource, data source, or block type. When the parser encounters a property name that isn't in the schema, it raises this error. This is different from HCL syntax errors—the JSON is valid JSON, but the Terraform schema rejects the property name as extraneous (unnecessary/unexpected). This typically happens when property names are misspelled, outdated, or using incorrect naming conventions.
Typical symptoms
- Terraform validate or plan fails with 'Extraneous JSON object property' error
- Error message specifies which property is extraneous and which resource/block it occurred in
- The property name is clearly listed in the error message
- Works fine when converted to equivalent HCL (.tf) syntax
- Property exists in provider documentation but uses different naming
Common causes
- Misspelled property name (typo in argument or block type name)
- Using snake_case when the schema expects camelCase or vice versa
- Property doesn't exist for that resource type (checking wrong documentation)
- Outdated property name from older Terraform or provider version
- Using variable block with 'label' instead of 'type', 'default', or 'description'
- Custom naming conventions that don't match provider schema
- Copy-pasting properties from different resource types with incompatible schemas
How to fix "Error: Extraneous JSON object property"
The error clearly states which property is extraneous and in which resource or block. Example:
`Error: Extraneous JSON object property
on main.tf.json line 5, in resource "aws_instance" "example":
5: "instance_label": "my-server"
No argument or block type is named 'instance_label'.`
Note the exact property name that's problematic.
Search the provider documentation (e.g., https://registry.terraform.io/providers/hashicorp/aws/) for the resource type mentioned in the error. Find the exact argument name in the documentation.
For example, for aws_instance, you might find the argument is actually instance_initiated_shutdown_behavior not instance_label.
Update your .tf.json file with the correct property name from the documentation:
Wrong:
{
"resource": {
"aws_instance": {
"example": {
"instance_label": "my-server"
}
}
}
}Correct:
{
"resource": {
"aws_instance": {
"example": {
"tags": {
"Name": "my-server"
}
}
}
}
}Check that the property is valid for the specific resource type. The same property name might exist for aws_instance but not aws_security_group. Use the provider's registry documentation specific to that resource.
For blocks like variable, valid arguments are only: type, default, and description. Any other property (like label, name, or required) will cause this error.
Terraform JSON uses snake_case for property names. Make sure you're not using camelCase or other conventions:
Wrong (camelCase):
{ "instanceType": "t2.micro" }Correct (snake_case):
{ "instance_type": "t2.micro" }After fixing the property name, validate your configuration:
terraform validateIf validation passes, your JSON configuration is now correct.
If you have many JSON configuration files, consider converting to HCL (.tf files) instead. HCL is more readable and is Terraform's native language:
terraform show -json yourstate.tfstate > state.json
terraform import -config=... # if neededAlternatively, use jsonencode() in HCL when you need JSON: policy = jsonencode({...})
Advanced notes
JSON vs HCL: Terraform supports both .tf.json (JSON) and .tf (HCL) files in the same directory. The JSON syntax mirrors HCL exactly. When in doubt, use HCL—it's more forgiving and widely used.
Schema validation: Terraform validates JSON against the provider schema, which includes argument names and block types. The schema comes from the provider plugin and varies between providers and versions.
Generated JSON: Tools that generate Terraform JSON (like Terraform CDK, Pulumi JSON output, or CloudFormation converters) may produce incorrect property names if misconfigured. Always validate generated JSON with terraform validate.
Nested objects: In JSON, nested objects must match the exact property structure. For example, tags is an object with string key-value pairs, while security_groups is an array of strings. Mismatching these structures causes similar errors.
Frequently asked questions
- What does "Error: Extraneous JSON object property" mean?
- json) against a schema of valid arguments and block types for each resource, data source, or block type. When the parser encounters a property name that isn't in the schema, it raises this error. This is different from HCL syntax errors—the JSON is valid JSON, but the Terraform schema rejects the property name as extraneous (unnecessary/unexpected).
- How do I fix "Error: Extraneous JSON object property"?
- This error occurs when using Terraform JSON configuration files (.tf.json) with property names that don't match valid arguments or block types for the resource or block being configured. The error indicates an unrecognized attribute.
- What causes "Error: Extraneous JSON object property"?
- Misspelled property name (typo in argument or block type name) Using snake_case when the schema expects camelCase or vice versa Property doesn't exist for that resource type (checking wrong documentation)
- Is the "Error: Extraneous JSON object property" error serious?
- It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.