When Unstructured partitions a file, the result is a list of document elements, sometimes referred to simply as elements. These elements represent different components of the source file.
Element example
Here’s an example of what an element might look like:text; and some metadata which might
vary depending on the element type, file structure, and some additional settings that are applied during
partitioning, chunking, and enriching. Optionally, the element can also have an
embeddings derived from the text; the length of embeddings depends on the embedding model that is used.
Element type
Instead of treating all files as strings of plain text, Unstructured preserves the semantic structure of the files. This gives you more control and flexibility over how you further use the processed files and allows you to take their structure into consideration. At the same time, normalizing data from various file formats to the Unstructured element type scheme lets you treat all files the same in your downstream processing, regardless of source format. For example, if you plan to summarize a file, you might only be interested in the narrative of the file and not care about its headers and footers. You can easily filter out the elements you don’t need by specifying their type. Here are some examples of the element types your file might contain:SceneDescription and TranscriptFragment are specific to video and audio file processing, which is available only for self-hosted deployments of Unstructured.CompositeElement type.
CompositeElement is a chunk formed from text (non-Table) elements.
A composite element might be formed by combining one or more sequential elements produced by partitioning. For example,
several individual list items might be combined into a single chunk.
For the most up-to-date list of available element types, see the TYPE_TO_TEXT_ELEMENT_MAP type-annotated mapping definition and the
ElementType class definition in the elements.py
file, located in the Unstructured-IO/unstructured
repository in GitHub.
Element ID
By default, the element ID is a SHA-256 hash of the element’s text, its position on the page, the page number it’s on, and the name of the related file. This is to ensure that the ID is deterministic and unique at the file level.Metadata
Unstructured tracks a variety of metadata about the elements extracted from files. Metadata is tracked at the element level withinmetadata.
Element metadata enables you to do things such as:
- Filter file elements based on an element’s metadata value. For instance, you might want to limit your scope to elements from a certain page, or you might want to use only elements that have an email matching a regular expression in their metadata.
- Map an element to the page where it occurred so that the original page can be retrieved when that element matches search criteria.
ElementMetadata class definition in the elements.py
file, located in the Unstructured-IO/unstructured
repository in GitHub.
Common metadata fields
All file types return the followingmetadata fields when the information is available from the source file:
Notes on common metadata fields:
Document hierarchy
parent_id and category_depth enhance hierarchy detection to identify the document
structure in various file formats by measuring relative depth of an element within its category. This is especially
useful in files with native hierarchies like HTML or Word files, where elements like headings or list items inherently define structure.
Element coordinates
Some file types support location data for the elements, usually in the form of bounding boxes. Thecoordinates metadata field contains:
points: These specify the corners of the bounding box starting from the top left corner and proceeding counter-clockwise. The points represent pixels, the origin is in the top left and theycoordinate increases in the downward direction.system: The points have an associated coordinate system. A typical example of a coordinate system isPixelSpace, which is used for representing the coordinates of images. The coordinate system has a name, orientation, layout width, and layout height.
Additional metadata fields by file type
Here are some notes on additional metadata fields by file type:
bcc_recipientcc_recipientemail_message_idsent_fromsent_tosignaturesubject
sent_from is a list of strings because the RFC 822 spec for emails allows for multiple sent from email addresses.
Microsoft Excel files
For Excel files, metadata will contain apage_name element, which corresponds to the sheet name in the Excel
file.
Microsoft Word files
Headers and footers in Word files include aheader_footer_type indicating which page a header or footer applies to.
Valid values are "primary", "even_only", and "first_page".
Video files
Elements for video files include astart_time and end_time, representing the start and end times of a clip of video
from the parent video file to which this element belongs. Also included are the model_version representing the model that was used to
generate the element, and the average_log_probability representing the model’s overall average confidence level for the model’s output across the document, with values closer to
zero indicating higher confidence.
Audio files
Elements for audio files include astart_time, end_time, and speaker, representing the start and end times of a clip of audio
made by a specific speaker, as part of the parent audio file to which this element belongs.
If the speaker cannot be determined, speaker is set to 0 or unknown.
Table-specific metadata
ForTable elements, the raw text of the table will be stored in the text attribute for the element, and HTML representation
of the table will be available in the element metadata under text_as_html.
Unstructured will automatically extract all tables for all doc types if you check the Infer Table Structure in the ConnectorSettings area of the Transform section of a workflow.
Here’s an example of a table element. The text of the element will look like this (line breaks are added here for readability):
text_as_html metadata for the same element will look like this (line breaks are added here for readability):
Data connector metadata fields
Documents can include additional file metadata, based on the specified source connector.Common data connector metadata fields
date_createddate_modifieddate_processedpermissions_datarecord_locatorurlversion
Additional metadata fields by connector type (within record_locator)
VLM generated HTML elements
The vision language model (VLM) partitioner also generates an HTML representation of the Unstructured elements that are produced. Unstructured has developed an element ontology that assigns incoming Unstructured elements to these various defined element ontology types. These element ontology types are used to generate standard HTML elements with the element ontology type as class attributes on those HTML elements. The generated HTML elements are output astext_as_html along with their parent_id in metadata, to allow for easier HTML reconstruction of the entire document as needed.
For example, given the following table element produced with the VLM partitioner, the text_as_html field is an HTML representation of the
derived table, and parent_id is the element_id of the Unstructured element for the page that contains this table. (Line breaks are added here to the
text and text_as_html fields for readability.)

