Unity 6.2: Catching and Fixing Malformed `.asset`, `.prefab`, or `.unity` Files Before They Break Your Project

Summary

Unity 6.2 (and newer) now reports common .asset, .prefab, and .unity YAML issues that were previously ignored — including unknown types, invalid script references, type mismatches, missing headers, and low‑level parsing errors with improved context.
Fixing these early will improve long‑term project stability, prevent hidden data loss, and save you from chasing down hard‑to‑reproduce bugs later.
You can clean affected assets using the attached helper script or by manually resaving them, and follow our prevention tips to avoid future corruption.


Background

Unity .asset, .prefab, and .unity files are stored in a YAML‑like text format.
While this makes them human‑readable and easy to version‑control, it also means they can become malformed — often due to:

  • Manual editing
  • Automated tooling errors
  • Git merge conflicts (the most common culprit)

Before Unity 6.2, Unity’s internal checks for file validity were silent. If a file loaded, Unity assumed it was fine — even if parts of it were broken. In many cases, Unity would simply discard malformed data without telling you.

From Unity 6.2, we’ve introduced basic reporting for common YAML issues.
These checks are not exhaustive, but they will flag problems early in development, helping you avoid subtle data loss or editor crashes.
By resolving these problems sooner, you’ll improve your project’s long‑term stability, reduce the risk of hidden data loss, and save time debugging issues that might otherwise surface much later in development.


Why This Matters

Previously, corrupted or incomplete data could:

  • Cause random crashes in the Unity Editor.
  • Lead to missing or incorrect data in scenes and prefabs.
  • Go completely unnoticed until much later in development.

Now, Unity will log explicit error messages when it detects certain issues — giving you the opportunity to fix them before they cause downstream problems.


Examples of New Error Messages in Unity 6.2

When Unity detects malformed YAML data, you may now see errors such as:

  • Unknown type
    Example:
    Unknown type 'sometype' for FileID 1234 in text file 'source_file' at line 123.
    What it means: The file references a type that Unity doesn’t recognise — often caused by a missing script, renamed class, or merge conflict that altered the type name.
    Extra note: If the asset originates from a very old version of Unity, it’s possible the type was valid in that version but no longer exists. In such cases, and especially if you believe the data should still be supported, it may be worth reporting a bug to Unity so the team can investigate.
  • Invalid Script reference
    Example:
    Invalid Script reference on non-host type 'GameObject' in text file 'source_file' at line 123.
    What it means: Scripts can only be attached to specific types that are capable of hosting them — such as MonoBehaviour or ScriptedImporter. This error often appears when YAML lines are incorrectly merged, for example: if a m_Script field ends up under a non-host type like Mesh or GameObject.
  • Type mismatch
    Example:
    Type mismatch. Expected type 'A', but found 'B' at FileID 1234 in text file 'source_file' at line 123.
    What it means: The persistent type ID in the YAML header (!u!<number>) doesn’t match the type name that follows.
    Example: !u!1 (GameObject) followed by MonoBehaviour: will trigger this. Usually caused by merge conflicts, manual edits, or corrupted serialization.
  • Missing class type header
    Example:
    Failed to parse data as no preceding class type header in text file 'source_file' at line 123.
    What it means: A YAML object is missing its required header line (e.g., --- !u!114 &123456789). Without this, Unity can’t determine what the following data belongs to.
  • General YAML parsing errors (new in 6.2)
    Unity now reports low‑level parsing failures with improved context:
    • Could not extract 'TypeID' at "2147483648 &16" in text file 'source_file' at line 3.
      What it means: The value is invalid or too large to fit in Unity’s internal type representation.
    • Failed to parse at " 456 &" in text file 'source_file' at line 4.
      What it means: The YAML header format is invalid — for example, extra spaces or missing required symbols.

What You Should Do

  • Test your project in Unity 6.2 or any newer release — these versions have the most complete set of checks.
  • If you see errors in Asset Store packages, report them to the asset’s developer.
  • Share this information with your team so everyone understands the new warnings.

How to Remove the Issues

If the asset has been in use for a long time, Unity has likely already discarded the malformed data internally.
If you haven’t noticed any issues in‑game or in the editor, it’s likely safe to simply clean out the ignored data to remove these errors.

You can do this by loading the asset, marking it dirty, and saving it again:

var obj = AssetDatabase.LoadMainObjectAtPath(assetPath);
EditorUtility.SetDirty(obj);
AssetDatabase.SaveAssetIfDirty(obj);

:warning: Important: This is destructive — any unused or invalid data will be permanently removed.
Always back up your assets first.

For convenience, we’ve attached a user‑friendly script below that walks through this process and provides warnings before making changes. This may be extended or customised to best suite your needs.

FixMalformedAssets.cs (13.1 KB)
Note: CodeSmile noted this script is using AssetDatabase.SaveAssets() which will save all modified assets in the project and not just the affected assets - please check if you have other undesired changes before using this script as-is.


Other Fix Options

  • Source Control: If you use Git, try to identify when the file became malformed and restore a clean version.
  • Regenerate: If the file is generated by tooling, update the tool and regenerate the asset.
  • Manual Repair: For advanced users, you can manually edit the YAML — but be careful, as incorrect edits can make things worse.

Tips to Prevent YAML Corruption

While Unity 6.2 helps detect issues, prevention is even better. Here are some best practices:

  1. Use the right merge strategy for Unity assets
    There are two main approaches, depending on whether you want to merge or block merges for .asset/.prefab/.unity files:
  • Option A – Treat as binary (no merging)
    Use this if you don’t want to risk partial merges corrupting YAML.
*.asset binary
*.prefab binary
*.unity binary
  • Option B – Use Unity’s Smart Merge (UnityYAMLMerge)
    This lets Git attempt a structured merge using Unity’s own YAML parser.
*.asset merge=unityyamlmerge eol=lf
*.prefab merge=unityyamlmerge eol=lf
*.unity merge=unityyamlmerge eol=lf
  1. Avoid manual YAML edits unless absolutely necessary
    If you must edit, validate the file with a YAML linter before committing.

  2. Keep tooling up to date
    Outdated asset‑generation tools can produce malformed files.

  3. Run validation before committing
    Add a pre‑commit hook to run Unity in batch mode and check for asset errors.

  4. Regular backups
    Even with source control, periodic backups can save time when recovering from corruption.


Final Notes

These checks are just the beginning — they don’t catch every possible YAML corruption.
Some complex cases (like missing headers in the middle of a file) are still hard to detect automatically, but the new system will catch many of the most common and dangerous issues.

By testing your project in Unity 6.2 or newer now, you can catch and fix problems early — before they cause instability or data loss.

10 Likes

Aaaaah, this is much needed reporting! Curious when I’ll run into these the first time.


Can’t help but correct this:

It should be:

var obj = AssetDatabase.LoadMainObjectAtPath(assetPath);
EditorUtility.SetDirty(obj);
AssetDatabase.SaveAssetIfDirty(obj);

Since this sample shouldn’t call “Save Project” (everything) but rather just save the modified asset. :wink:

2 Likes

Thankyou for spotting this improvement, I will make this change to the OP. I am aware SaveAssets() is still useful for batch operations I gather.

As a “lazy solution” yes. But it can lead to surprises if a script unexpectedly saves everything, including things the user meant to discard. I tend to be very cautious with that as I recall certain changes are not undoable after saving.

1 Like

Does this mean a component with a m_GameObject: {fileID: gameobject_id} for a GameObject that doesn’t have the corresponding - component: {fileID: component_id}?

1 Like