How to Extract Metadata from 3D Model Files

Every 3D model file carries more than geometry. Alongside vertices, edges, and faces, these files store metadata that describes how the model was built, what software created it, and how it should be rendered. This metadata matters for asset management, version control, format conversion, and compliance workflows.

The specific metadata fields depend on the format. A glTF file stores structured JSON metadata for scenes, nodes, and materials. An FBX file can embed take names, frame rates, and bone hierarchies. An OBJ file relies on comment lines and companion .mtl files. The differences are significant enough that you need format-specific strategies for extraction.

Common metadata fields across 3D formats include:

• Authoring software and version (Blender 4.2, Maya 2025, SolidWorks 2024)
• Polygon and vertex counts for the entire scene or per-mesh
• Material definitions including texture references, shader parameters, and color values
• Scene hierarchy with parent-child node relationships
• Units of measurement (meters, centimeters, inches)
• Animation data such as keyframe counts, frame rates, and bone/joint names
• Custom properties added by artists or pipeline tools
• Coordinate system orientation (Y-up vs. Z-up)

Understanding what metadata each format supports helps you choose the right extraction approach and avoid losing information during format conversions.

Each 3D format handles metadata differently. Some formats treat metadata as a first-class feature with structured storage, while others barely support it. Here is what you can expect from the five most common formats.

glTF and GLB

glTF 2.0, often called the "JPEG of 3D," stores metadata in structured JSON. The top-level asset object is required by the specification and contains a version field (always "2.0"), an optional generator field naming the authoring tool, and optional copyright and minVersion fields. Beyond the asset block, the entire scene graph is readable JSON: every scene, node, mesh, material, texture, animation, and skin is a named object with typed properties.

This makes glTF the easiest format to inspect. You can open a .gltf file in any text editor and read the scene hierarchy, material parameters (PBR metallic-roughness values, texture indices), mesh primitive counts, and accessor definitions that describe vertex attribute layouts. GLB files pack the same JSON into a binary container, but tools like gltf-transform or a simple binary parser can extract the JSON chunk.

glTF also supports extensions. The KHR_xmp_json_ld extension (formerly KHR_xmp) allows embedding XMP metadata packets with Dublin Core fields like creator, description, and rights. Custom extensions can carry pipeline-specific metadata without breaking standard viewers.

FBX

Autodesk's FBX format stores metadata in a proprietary binary or ASCII structure. The global settings section contains the coordinate system (which axis is up, which is front), the unit scale factor, the original authoring application, and creation timestamps. Animation metadata is particularly rich: FBX files embed animation take names, start and end frame numbers, frame rates, and full skeletal hierarchies with bone names and bind poses.

FBX also carries user-defined properties on any node in the scene tree. These custom properties are commonly used by game engines. Unreal Engine, for example, reads FBX metadata through its Asset Metadata Pipeline, mapping custom properties to asset tags that drive content browser searches and automation rules.

The downside is that FBX metadata is not human-readable in binary mode. You need the Autodesk FBX SDK, the FBX Review tool, or a library like Aspose.3D to parse it programmatically.

OBJ and MTL

The Wavefront OBJ format is deliberately minimal. It has no formal header or metadata block. Instead, metadata appears in comment lines (prefixed with #) at the top of the file. Most exporters write the software name and version, export date, vertex count, and face count as comments, but there is no standard for which fields appear or how they are formatted.

Material metadata lives in a separate .mtl (Material Template Library) file, referenced from the OBJ via the mtllib directive. The MTL file defines ambient, diffuse, and specular colors, transparency, shininess, and texture map paths. Group names (g) and object names (o) in the OBJ file provide basic scene organization, but nothing approaching the structured hierarchy of glTF or FBX.

Because OBJ metadata is informal, parsing it requires string matching against comment patterns rather than structured deserialization.

STL

STL is the most metadata-limited 3D format in common use. Binary STL files begin with an 80-byte header that is technically free-form text, followed by a triangle count and raw triangle data. That 80-byte header is the only place metadata can live, and most software ignores it entirely. There is no standard for what goes in the header, no units specification, no material support, no color data, and no scene hierarchy.

ASCII STL files include a solid keyword followed by an optional name, but again there is no structured metadata. The format was designed in 1987 for stereolithography printing and has never been extended with metadata capabilities.

If you need metadata from an STL file, you are limited to the 80-byte header, the triangle count, and whatever you can compute from the geometry itself (bounding box, surface area, volume).

STEP (ISO 10303)

STEP files store the richest metadata of any common 3D format. As an ISO standard for product data exchange, STEP includes structured entities for authoring organization, document identifiers, approval status, material specifications, geometric tolerances, and product manufacturing information (PMI). The file is plain text using the EXPRESS data modeling language, making it grep-friendly.

NIST provides a free STEP File Analyzer and Viewer that generates spreadsheets of all entity and attribute information, reports on PMI data, and checks for format compliance errors. CAD tools like SolidWorks, CATIA, and Siemens NX can extract STEP metadata natively, and libraries like Open Cascade provide programmatic access through C++ and Python bindings.

You do not always need to write code to inspect 3D metadata. Several desktop and web-based tools handle common formats out of the box.

Blender opens glTF, FBX, OBJ, STL, and many other formats. After importing a file, the Properties panel shows object-level metadata, material settings, and scene properties. The Outliner panel displays the full scene hierarchy. For glTF files specifically, Blender preserves custom extensions and extras data through its import/export pipeline.

FBX Review is a free standalone viewer from Autodesk that displays FBX scene contents, including take lists, node hierarchies, materials, and animation metadata. It does not edit files, but it gives a quick read on what is inside.

glTF Viewer tools include the Khronos glTF Sample Viewer, Don McCurdy's glTF Viewer, and BabylonJS Sandbox. These browser-based tools parse and display the full JSON structure of glTF/GLB files, making them useful for quick inspections without installing software.

NIST STEP File Analyzer generates comprehensive spreadsheets from STEP files, covering every entity type, geometric property, and PMI annotation in the file.

Aspose 3D online tools offer browser-based FBX and glTF metadata extractors that parse files and display properties without requiring a local installation.

For batch workflows, command-line tools scale better. The gltf-transform CLI can inspect, optimize, and modify glTF files. The meshlab CLI (meshlabserver) processes OBJ and STL files with scriptable filters. And trimesh, covered in the next section, works from both Python scripts and the command line.

Organize Your 3D Assets and Project Files

Fast.io workspaces give your team a shared space for 3D models, specifications, and project documents with built-in AI search and metadata extraction. 50 GB free, no credit card required.

Sign Up Free

Programmatic extraction is where 3D metadata workflows become practical at scale. Here are the main libraries and approaches for each format.

Python with trimesh

The trimesh library loads STL, OBJ, PLY, glTF/GLB, and other formats into Python objects with accessible metadata. After loading a scene, you can inspect vertex counts, face counts, bounding boxes, units, and the scene graph structure.

import trimesh

scene = trimesh.load("model.glb")

if isinstance(scene, trimesh.Scene):
    for name, geometry in scene.geometry.items():
        print(f"{name}: {len(geometry.vertices)} vertices, "
              f"{len(geometry.faces)} faces")
    print(f"Scene bounds: {scene.bounds}")
    print(f"Units: {scene.units}")

trimesh handles format differences internally. It parses glTF JSON metadata, reads OBJ comments and MTL files, and computes geometric properties from STL triangle data. For glTF files, the scene.metadata dictionary contains the parsed asset block with generator, version, and copyright fields.

glTF with gltf-transform (Node.js)

The gltf-transform library from Don McCurdy provides fine-grained access to every part of a glTF file. You can read and write extensions, inspect buffer layouts, and extract material parameters.

import { NodeIO } from '@gltf-transform/core';

const io = new NodeIO();
const document = await io.read('model.glb');
const root = document.getRoot();

console.log('Generator:', root.getAsset().generator);
console.log('Meshes:', root.listMeshes().length);
console.log('Materials:', root.listMaterials().length);
console.log('Animations:', root.listAnimations().length);

for (const material of root.listMaterials()) {
    console.log(`Material: ${material.getName()}`);
    console.log(`  Base color: ${material.getBaseColorFactor()}`);
    console.log(`  Metallic: ${material.getMetallicFactor()}`);
    console.log(`  Roughness: ${material.getRoughnessFactor()}`);
}

FBX with the Autodesk FBX SDK

The official FBX SDK is available for C++, Python, and several other languages. It exposes the full scene tree including global settings, custom properties, and animation stacks.

import fbx

manager = fbx.FbxManager.Create()
importer = fbx.FbxImporter.Create(manager, "")
importer.Initialize("model.fbx")

scene = fbx.FbxScene.Create(manager, "")
importer.Import(scene)

settings = scene.GetGlobalSettings()
print(f"Up axis: {settings.GetAxisSystem().GetUpVector()}")
print(f"Unit: {settings.GetSystemUnit().GetScaleFactor()}")
print(f"Frame rate: {settings.GetTimeMode()}")

root = scene.GetRootNode()
print(f"Child nodes: {root.GetChildCount()}")

The FBX SDK requires a separate download from Autodesk and platform-specific compilation. For simpler needs, Aspose.3D for Python provides a higher-level API that reads FBX metadata without the SDK setup overhead.

STEP with Open Cascade

For STEP files, the Open Cascade Technology (OCCT) library and its Python wrapper pythonocc-core provide full access to product data, geometric properties, and PMI annotations. This is the standard approach for CAD metadata extraction in manufacturing and engineering pipelines.

Extracting metadata from a single file is straightforward. The harder problem is tracking metadata across hundreds or thousands of 3D assets in a production pipeline. Game studios, architecture firms, and product design teams all deal with asset libraries where knowing the polygon count, material count, and authoring tool for every file matters for optimization and compatibility.

Local scripts work for small teams. A Python script using trimesh can walk a directory, extract key fields from every supported file, and write the results to a CSV or database. This approach breaks down when files live in multiple locations, when team members need to query results without running scripts, or when metadata needs to stay current as files change.

Cloud-based platforms handle the organizational layer. Fast.io's Metadata Views let you define extraction schemas in natural language and apply them across files in a workspace. For 3D project workflows, this means you can extract metadata from the documents that surround your 3D assets: specification sheets, material lists, vendor quotes, and approval forms. Describe the fields you want (material name, approved date, vendor, cost), and the AI builds a typed schema and populates a sortable spreadsheet from your uploaded documents.

For the 3D files themselves, a practical pipeline combines format-specific extraction scripts with a shared workspace where results are stored and searchable. Upload your 3D assets and their extracted metadata reports to a Fast.io workspace, and the files are automatically indexed for search and AI chat when Intelligence is enabled. Team members can search for assets by name, and project managers can query across documents without digging through folder structures.

Version control adds another dimension. When a 3D artist updates a model, the metadata changes. Polygon counts shift after optimization passes, materials get renamed, and animation takes get added or removed. Tracking these changes matters for QA and for downstream consumers who depend on specific asset properties. Audit trails provide a record of when files were updated, by whom, and what changed.

Not every format gives you what you need. Here are the most common problems and how to work around them.

STL files with no useful metadata. Since STL has no structured metadata support, the standard workaround is to maintain a sidecar file (JSON, XML, or YAML) with the metadata you need. Many 3D printing services do this automatically, generating a properties file alongside each STL with computed values like volume, surface area, bounding box dimensions, and wall thickness. If you control the export pipeline, consider switching to 3MF, which was designed as a metadata-rich replacement for STL in additive manufacturing.

OBJ comment-based metadata is inconsistent. Every exporter writes different comment formats. Blender writes vertex and face counts; Maya writes the software version and export date; some tools write nothing at all. If you need reliable metadata from OBJ files, parse the geometry directly to compute vertex and face counts, read the MTL file for material data, and treat comments as supplementary information rather than ground truth.

FBX binary files resist inspection. Unlike glTF's readable JSON, binary FBX requires a parser. If you need quick metadata checks without writing code, convert the FBX to glTF using a tool like Blender or the fbx2gltf converter, then inspect the resulting JSON. This adds a step but gives you human-readable output. Keep the original FBX as the source of truth, since conversion can lose custom properties and extension data.

Mixed coordinate systems cause confusion. glTF uses Y-up with a right-handed coordinate system. FBX defaults to Y-up but many exporters override this. OBJ has no coordinate system specification. When extracting position or orientation metadata, always check the coordinate system and unit scale before comparing values across formats.

Custom metadata does not survive format conversion. This is the biggest practical limitation. Custom properties in FBX, extras in glTF, and comment metadata in OBJ are all format-specific. Converting between formats almost always drops custom metadata. The safest approach is to extract custom metadata before conversion and store it in a sidecar file or external database.