This field contains a constant value and can be used to quickly identify a file as being an HDF5 file. The constant value is designed to allow easy identification of an HDF5 file and to allow certain types of data corruption to be detected. The file signature of an HDF5 file always contains the following values:

This signature both identifies the file as an HDF5 file and provides for immediate detection of common file-transfer problems. The first two bytes distinguish HDF5 files on systems that expect the first two bytes to identify the file type uniquely. The first byte is chosen as a non-ASCII value to reduce the probability that a text file may be misrecognized as an HDF5 file; also, it catches bad file transfers that clear bit 7. Bytes two through four name the format. The CR-LF sequence catches bad file transfers that alter newline sequences. The control-Z character stops file display under MS-DOS. The final line feed checks for the inverse of the CR-LF translation problem. (This is a direct descendent of the PNG file signature.)

This field is present in version 0+ of the superblock.

This value is used to determine the format of the information in the super block. When the format of the information in the super block is changed, the version number is incremented to the next integer and can be used to determine how the information in the super block is formatted.

Values of 0 and 1 are defined for this field.

This field is present in version 0+ of the superblock.

This value is used to determine the format of the information in the File Free-space Information.

The only value currently valid in this field is '0', which indicates that the free space index is formatted as described below.

This field is present in version 0+ of the superblock.

This value is used to determine the format of the information in the Root Group Symbol Table Entry. When the format of the information in that field is changed, the version number is incremented to the next integer and can be used to determine how the information in the field is formatted.

The only value currently valid in this field is '0', which indicates that the root group symbol table entry is formatted as described below.

This field is present in version 0+ of the superblock.

This value is used to determine the format of the information in a shared object header message. Since the format of the shared header messages differs from the other private header messages, a version number is used to identify changes in the format.

The only value currently valid in this field is '0', which indicates that shared header messages are formatted as described below.

This field is present in version 0+ of the superblock.

This value contains the number of bytes used to store addresses in the file. The values for the addresses of objects in the file are offsets relative to a base address, usually the address of the super block signature. This allows a wrapper to be added after the file is created without invalidating the internal offset locations.

This field is present in version 0+ of the superblock.

This value contains the number of bytes used to store the size of an object.

This field is present in version 0+ of the superblock.

Each leaf node of a group B-tree will have at least this many entries but not more than twice this many. If a group has a single leaf node then it may have fewer entries.

This value must be greater than zero.

See the description of B-trees below.

This field is present in version 0+ of the superblock.

Each internal node of a group B-tree will have at least this many entries but not more than twice this many. If the group has only one internal node then it might have fewer entries.

This value must be greater than zero.

See the description of B-trees below.

This field is present in version 0+ of the superblock.

This value contains flags to indicate information about the consistency of the information contained within the file. Currently, the following bit flags are defined:

• Bit 0 set indicates that the file is opened for write-access.
• Bit 1 set indicates that the file has been verified for consistency and is guaranteed to be consistent with the format defined in this document.
• Bits 2-31 are reserved for future use.

This field is present in version 0+ of the superblock.

Each internal node of a indexed storage B-tree will have at least this many entries but not more than twice this many. If the group has only one internal node then it might have fewer entries.

This value must be greater than zero.

See the description of B-trees below.

This field is present in version 1+ of the superblock.

This is the absolute file address of the first byte of the HDF5 data within the file. The library currently constrains this value to be the absolute file address of the super block itself when creating new files; future versions of the library may provide greater flexibility. When opening an existing file and this address does not match the offset of the superblock, the library assumes that the entire contents of the HDF5 file have been adjusted in the file and adjusts the base address and end of file address to reflect their new positions in the file. Unless otherwise noted, all other file addresses are relative to this base address.

This field is present in version 0+ of the superblock.

Free-space management is not yet defined in the HDF5 file format and is not handled by the library. Currently this field always contains the undefined address.

This field is present in version 0+ of the superblock.

This is the absolute file address of the first byte past the end of all HDF5 data. It is used to determine whether a file has been accidently truncated and as an address where file data allocation can occur if space from the free list is not used.

This field is present in version 0+ of the superblock.

This is the relative file address of the file driver information block which contains driver-specific information needed to reopen the file. If there is no driver information block then this entry should be the undefined address.

This field is present in version 0+ of the superblock.

This is the symbol table entry of the root group, which serves as the entry point into the group graph for the file.

This field is present in version 0+ of the superblock.

The version number of the driver information block. The file format documented here is version zero.

The size in bytes of the Driver Information part of this structure.

This is an eight-byte ASCII string without null termination which identifies the driver and version number of the Driver Information block. The predefined drivers supplied with the HDF5 library are identified by the letters NCSA followed by the first four characters of the driver name. If the Driver Information block is not the original version then the last letter(s) of the identification will be replaced by a version number in ASCII.

For example, the various versions of the multi driver will be identified by NCSAmult. (NCSAmult is simply NCSAmulti truncated to eight characters. Subsequent identifiers will be created by substituting sequential numerical values for the final character, starting with zero.) multi driver is the only default driver that is encoded in this field.

Identification for user-defined drivers is eight-byte long and arbitrary but should be unique and avoid the four character prefix "NCSA".

Multi driver enables different types of HDF5 data and metadata to be written to separate files. These files are viewed by the library as a single virtual HDF5 file with a single file address. It allows maximal 6 files to be created. In sequence, these Member Mapping fields are for super block, B-tree, raw data, global heap, local heap, and object header. More than one type of data can be written to the same file.

These Member Mapping fields are integer values from 1 to 6 indicating how the data can be mapped to or merged with another type of data.

Member Mapping	Description
1	The super block data.
2	The B-tree data.
3	The raw data.
4	The global heap data.
5	The local heap data.
6	The object header data.

These fields are reserved and should always be zero.

Specifies the virtual address. A normally eight-byte integer with the value from 0 (zero) to maximal value, at which the member file starts.

The end of allocated address for the member file. A normally eight-byte integer value.

The null-terminated name of member file. Its length should be multiples of 8 bytes. Additional bytes will be padded with NULLs. The default naming convention is %%s-X.h5, where X is one of the letters s (for super block), b (for B-tree), r (for raw data), g (for global heap), l (for local heap), and o (for object header). The name for the whole HDF5 file will substitute the %s in the string.

The ASCII character string "TREE" is used to indicate the beginning of a B-link tree node. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Each B-link tree points to a particular type of data. This field indicates the type of data as well as implying the maximum degree K of the tree and the size of each Key field.

The node level indicates the level at which this node appears in the tree (leaf nodes are at level zero). Not only does the level indicate whether child pointers point to sub-trees or to data, but it can also be used to help file consistency checking utilities reconstruct damanged trees.

This determines the number of children to which this node points. All nodes of a particular type of tree have the same maximum degree, but most nodes will point to less than that number of children. The valid child pointers and keys appear at the beginning of the node and the unused pointers and keys appear at the end of the node. The unused pointers and keys have undefined values.

This is the relative file address of the left sibling of the current node. If the current node is the left-most node at this level then this field is the undefined address.

This is the relative file address of the right sibling of the current node. If the current node is the right-most node at this level then this field is the undefined address.

Each tree has 2K+1 keys with 2K child pointers interleaved between the keys. The number of keys and child pointers actually containing valid values is determined by the node's Entries Used field. If that field is N then the B-link tree contains N child pointers and N+1 keys.

The format and size of the key values is determined by the type of data to which this tree points. The keys are ordered and are boundaries for the contents of the child pointer; that is, the key values represented by child N fall between Key N and Key N+1. Whether the interval is open or closed on each end is determined by the type of data to which the tree points.

The format of the key depends on the node type. For nodes of node type 0 (group nodes), the key is formatted as follows:

For nodes of node type 1 (chunked raw data nodes), the key is formatted as follows:

The tree node contains file addresses of subtrees or data depending on the node level. Nodes at Level 0 point to data addresses, either raw data chunk or group nodes. Nodes at non-zero levels point to other nodes of the same B-tree.

For raw data chunk nodes, the child pointer is the address of a single raw data chunk. For group nodes, the child pointer points to a symbol table, which contains information for multiple symbol table entries.

The ASCII character string "SNOD" is used to indicate the beginning of a group node. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

The version number for the group node. This document describes version 1. (There is no version '0' of the group node)

Although all group nodes have the same length, most contain fewer than the maximum possible number of symbol entries. This field indicates how many entries contain valid data. The valid entries are packed at the beginning of the group node while the remaining entries contain undefined values.

Each symbol has an entry in the group node. The format of the entry is described below. There are 2K entries in each group node, where K is the "Group Leaf Node K" value from the super block.

This is the byte offset into the group local heap for the name of the object. The name is null terminated.

Every object has an object header which serves as a permanent location for the object's metadata. In addition to appearing in the object header, some metadata can be cached in the scratch-pad space.

The cache type is determined from the object header. It also determines the format for the scratch-pad space:

Type:	Description:
0	No data is cached by the group entry. This is guaranteed to be the case when an object header has a link count greater than one.
1	Object header metadata is cached in the group entry. This implies that the group entry refers to another group.
2	The entry is a symbolic link. The first four bytes of the scratch-pad space are the offset into the local heap for the link value. The object header address will be undefined.
N	Other cache values can be defined later and libraries that do not understand the new values will still work properly.

These four bytes are present so that the scratch-pad space is aligned on an eight-byte boundary. They are always set to zero.

This space is used for different purposes, depending on the value of the Cache Type field. Any metadata about a dataset object represented in the scratch-pad space is duplicated in the object header for that dataset. This metadata can include the datatype and the size of the dataspace for a dataset whose datatype is atomic and whose dataspace is fixed and less than four dimensions.

Furthermore, no data is cached in the group entry scratch-pad space if the object header for the group entry has a link count greater than one.

This is the file address for the root of the group's B-tree.

This is the file address for the group's local heap, in which are stored the group's symbol names.

The value of a symbolic link (that is, the name of the thing to which it points) is stored in the local heap. This field is the 4-byte offset into the local heap for the start of the link value, which is null terminated.

The ASCII character string "GCOL" is used to indicate the beginning of a collection. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Each collection has its own version number so that new collections can be added to old files. This document describes version one (1) of the collections (there is no version zero (0)).

This is the size in bytes of the entire collection including this field. The default (and minimum) collection size is 4096 bytes which is a typical file system block size. This allows for 127 16-byte heap objects plus their overhead (the collection header of 16 bytes and the 16 bytes of information about each heap object).

The objects are stored in any order with no intervening unused space.

Global Heap Object 0 (zero), when present, represents the free space in the collection. Free space always appears at the end of the collection. If the free space is too small to store the header for Object 0 (described below) then the header is implied and the collection contains no free space.

Each object has a unique identification number within a collection. The identification numbers are chosen so that new objects have the smallest value possible with the exception that the identifier 0 always refers to the object which represents all free space within the collection.

All heap objects have a reference count field. An object which is referenced from some other part of the file will have a positive reference count. The reference count for Object 0 is always zero.

Zero padding to align next field on an 8-byte boundary.

This is the size of the object data stored for the object. The actual storage space allocated for the object data is rounded up to a multiple of eight.

The object data is treated as a one-dimensional array of bytes to be interpreted by the caller.

This value is used to determine the format of the information in the object header. When the format of the information in the object header is changed, the version number is incremented and can be used to determine how the information in the object header is formatted. This document describes version one (1) (there was no version zero (0)).

This value determines the number of messages listed in object headers for this object. This value includes the messages in continuation messages for this object.

This value specifies the number of "hard links" to this object within the current file. References to the object from external files, "soft links" in this file and object references in this file are not tracked.

This value specifies the number of bytes of header message data following this length field that contain object header messages for this object header. This value does not include the size of object header continuation blocks for this object elsewhere in the file.

This value specifies the type of information included in the following header message data. The header message types for the pre-defined header messages are included in sections below.

This value specifies the number of bytes of header message data following the header message type and length information for the current message. The size includes padding bytes to make the message a multiple of eight bytes.

This is a bit field with the following definition:

Bit	Description
0	If set, the message data is constant. This is used for messages like the datatype message of a dataset.
1	If set, the message is stored in the global heap. The Header Message Data field contains a Shared Object message and the Size of Header Message Data field contains the size of that Shared Object message.
2-7	Reserved

The format and length of this field is determined by the header message type and size respectively. Some header message types do not require any data and this information can be eliminated by setting the length of the message to zero. The data is padded with enough zeros to make the size a multiple of eight.

This value is used to determine the format of the Simple Dataspace Message. When the format of the information in the message is changed, the version number is incremented and can be used to determine how the information in the object header is formatted. This document describes version one (1) (there was no version zero (0)).

This value is the number of dimensions that the data object has.

This field is used to store flags to indicate the presence of parts of this message. Bit 0 (the least significant bit) is used to indicate that maximum dimensions are present. Bit 1 is used to indicate that permutation indices are present.

This value is the current size of the dimension of the data as stored in the file. The first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension stored is the fastest changing dimension.

This value is the maximum size of the dimension of the data as stored in the file. This value may be the special "unlimited" size which indicates that the data may expand along this dimension indefinitely. If these values are not stored, the maximum size of each dimension is assumed to be the dimension's current size.

This value is the index permutation used to map each dimension from the canonical representation to an alternate axis for each dimension. If these values are not stored, the first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension stored is the fastest changing dimension.

The version of the datatype message and the datatype's class information are packed together in this field. The version number is packed in the top 4 bits of the field and the class is contained in the bottom 4 bits.

The version number information is used for changes in the format of the datatype message and is described here:

Version	Description
0	Never used
1	Used by early versions of the library to encode compound datatypes with explicit array fields. See the compound datatype description below for further details.
2	The current version used by the library.

The class of the datatype determines the format for the class bit field and properties portion of the datatype message, which are described below. The following classes are currently defined:

Value	Description
0	Fixed-Point
1	Floating-Point
2	Time
3	String
4	Bitfield
5	Opaque
6	Compound
7	Reference
8	Enumerated
9	Variable-Length
10	Array

The information in these bit fields is specific to each datatype class and is described below. All bits not defined for a datatype class are set to zero.

The size of the datatype in bytes.

This variable-sized field encodes information specific to each datatype class and is described below. If there is no property information specified for a datatype class, the size of this field is zero.

The bit offset of the first significant bit of the fixed-point value within the datatype. The bit offset specifies the number of bits "to the right of" the value.

The number of bits of precision of the fixed-point value within the datatype.

The bit offset of the first significant bit of the floating-point value within the datatype. The bit offset specifies the number of bits "to the right of" the value.

The number of bits of precision of the floating-point value within the datatype.

The bit position of the exponent field. Bits are numbered with the least significant bit number zero.

The size of the exponent field in bits.

The bit position of the mantissa field. Bits are numbered with the least significant bit number zero.

The size of the mantissa field in bits.

The bias of the exponent field.

The number of bits of precision of the time value.

The bit offset of the first significant bit of the bitfield within the datatype. The bit offset specifies the number of bits "to the right of" the value.

The number of bits of precision of the bitfield within the datatype.

This NUL-terminated string provides a description for the opaque type. It is NUL-padded to a multiple of 8 bytes.

This NUL-terminated string provides a description for the opaque type. It is NUL-padded to a multiple of 8 bytes.

This is the byte offset of the member within the datatype.

If set to zero, this field indicates a scalar member. If set to a value greater than zero, this field indicates that the member is an array of values. For array members, the size of the array is indicated by the 'Size of Dimension n' field in this message.

This field was intended to allow an array field to have it's dimensions permuted, but this was never implemented. This field should always be set to zero.

This field is the size of a dimension of the array field as stored in the file. The first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension stored is the fastest changing dimension.

This field is a datatype message describing the datatype of the member.

This NUL-terminated string provides a description for the opaque type. It is NUL-padded to a multiple of 8 bytes.

This is the byte offset of the member within the datatype.

This field is a datatype message describing the datatype of the member.

Each enumeration type is based on some parent type, usually an integer. The information for that parent type is described recursively by this field.

The name for each name/value pair. Each name is stored as a null terminated ASCII string in a multiple of eight bytes. The names are in no particular order.

The list of values in the same order as the names. The values are packed (no inter-value padding) and the size of each value is determined by the parent type.

Each variable-length type is based on some parent type. The information for that parent type is described recursively by this field.

This value is the number of dimensions that the array has.

This value is the size of the dimension of the array as stored in the file. The first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension stored is the fastest changing dimension.

This value is the index permutation used to map each dimension from the canonical representation to an alternate axis for each dimension. Currently, dimension permutations are not supported and these indices should be set to the index position minus one (i.e. the first dimension should be set to 0, the second dimension should be set to 1, etc.)

Each array type is based on some parent type. The information for that parent type is described recursively by this field.

This is the size of the Fill Value field in bytes.

The fill value. The bytes of the fill value are interpreted using the same datatype as for the dataset.

The version number information is used for changes in the format of the fill value message and is described here:

Version	Description
0	Never used
1	Used by version 1.6.x of the library to encode fill values. In this version, the Size field is always present.
2	The current version used by the library (version 1.7.3 or later). In this version, the Size and Fill Value fields are only present if the Fill Value Defined field is set to 1.

When the storage space for the dataset's raw data will be allocated. The allowed values are:

Value	Description
1	Early allocation. Storage space for the entire dataset should be allocated in the file when the dataset is created.
2	Late allocation. Storage space for the entire dataset should not be allocated until the dataset is written to.
3	Incremental allocation. Storage space for the dataset should not be allocated until the portion of the dataset is written to. This is currently used in conjunction with chunked data storage for datasets.

At the time that storage space for the dataset's raw data is allocated, this value indicates whether the fill value should be written to the raw data storage elements. The allowed values are:

Value	Description
0	On allocation. The fill value is always written to the raw data storage when the storage space is allocated.
1	Never. The fill value should never be written to the raw data storage.
2	Fill value written if set by user. The fill value will be written to the raw data storage when the storage space is allocated only if the user explicitly set the fill value. If the fill value is the library default or is undefined, it will not be written to the raw data storage.

This value indicates if a fill value is defined for this dataset. If this value is 0, the fill value is undefined. If this value is 1, a fill value is defined for this dataset. For version 2 or later of the fill value message, this value controls the presence of the Size field.

This is the size of the Fill Value field in bytes. This field is not present if the Version field is >1 and the Fill Value Defined field is set to 0.

The fill value. The bytes of the fill value are interpreted using the same datatype as for the dataset. This field is not present if the Version field is >1 and the Fill Value Defined field is set to 0.

The version number information is used for changes in the format of External File List Message and is described here:

Version	Description
0	Never used.
1	The current version used by the library.

This field is reserved for future use.

The total number of slots allocated in the message. Its value must be at least as large as the value contained in the Used Slots field. (The current library simply uses the number of Used Slots for this message)

The number of initial slots which contains valid information.

This is the address of a local heap which contains the names for the external files (The local heap information can be found in Disk Format Level 1D in this document). The name at offset zero in the heap is always the empty string.

The slot definitions are stored in order according to the array addresses they represent.

The byte offset within the local name heap for the name of the file. File names are stored as a URL which has a protocol name, a host name, a port number, and a file name: protocol:port//host/file. If the protocol is omitted then "file:" is assumed. If the port number is omitted then a default port for that protocol is used. If both the protocol and the port number are omitted then the colon can also be omitted. If the double slash and host name are omitted then "localhost" is assumed. The file name is the only mandatory part, and if the leading slash is missing then it is relative to the application's current working directory (the use of relative names is not recommended).

This is the byte offset to the start of the data in the specified file. For files that contain data for a single dataset this will usually be zero.

This is the total number of bytes reserved in the specified file for raw data storage. For a file that contains exactly one complete dataset which is not extendable, the size will usually be the exact size of the dataset. However, by making the size larger one allows HDF5 to extend the dataset. The size can be set to a value larger than the entire file since HDF5 will read zeros past the end of the file without failing.

The version number information is used for changes in the format of the data layout message and is described here:

An array has a fixed dimensionality. This field specifies the number of dimension size fields later in the message.

The layout class specifies how the other fields of the layout message are to be interpreted. A value of one indicates contiguous storage, a value of two indicates chunked storage, while a value of zero indicates compact storage. Other values will be defined in the future.

For contiguous storage, this is the address of the first byte of storage. For chunked storage this is the address of the B-tree that is used to look up the addresses of the chunks. This field is not present for compact storage. If the version for this message is set to 2, the address may have the "undefined address" value, to indicate that storage has not yet been allocated for this array.

For contiguous and compact storage the dimensions define the entire size of the array while for chunked storage they define the size of a single chunk. In all cases, they are in units of array elements (not bytes). The first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension stored is the fastest changing dimension.

The size of a dataset element, in bytes. This field is only present for chunked storage.

This field is only present for compact data storage. It contains the size of the raw data for the dataset array.

This field is only present for compact data storage. It contains the raw data for the dataset array.

The version number information is used for changes in the format of layout message and is described here:

The layout class specifies how the other fields of the layout message are to be interpreted. A value of one indicates contiguous storage, a value of two indicates chunked storage, while a value of zero indicates compact storage.

This variable-sized field encodes information specific to each layout class and is described below. If there is no property information specified for a layout class, the size of this field is zero bytes.

This field contains the size of the raw data for the dataset array.

This field contains the raw data for the dataset array.

This is the address of the first byte of raw data storage. The address may have the "undefined address" value, to indicate that storage has not yet been allocated for this array.

This field contains the size allocated to store the raw data.

A chunk has a fixed dimensionality. This field specifies the number of dimension size fields later in the message.

This is the address of the B-tree that is used to look up the addresses of the chunks. The address may have the "undefined address" value, to indicate that storage has not yet been allocated for this array.

These values define the dimension size of a single chunk, in units of array elements (not bytes). The first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension stored is the fastest changing dimension.

The size of a dataset element, in bytes.

The version number for this message. This document describes version 1.

The total number of filters described by this message. The maximum possible number of filters in a message is 32.

A description of each filter. A filter description appears in the next table.

This value, often referred to as a filter identifier, is designed to be a unique identifier for the filter. Values from zero through 32,767 are reserved for filters supported by The HDF Group in the HDF5 library and for filters requested and supported by third parties. Filters supported by The HDF Group are documented immediately below. Information on 3rd-party filters can be found at https://support.hdfgroup.org/services/contributions.html#filters. ¹

To request a filter identifier, please contact The HDF Group’s Help Desk at . You will be asked to provide the following information:

1. Contact information for the developer requesting the new identifier
2. A short description of the new filter
3. Links to any relevant information, including licensing information

Values from 32768 to 65535 are reserved for non-distributed uses (for example, internal company usage) or for application usage when testing a feature. The HDF Group does not track or document the use of the filters with identifiers from this range.

The filters currently in library version 1.6.5 are listed below:

Identification	Name	Description
1	deflate	GZIP deflate compression
2	shuffle	Data element shuffling
3	fletcher32	Fletcher32 checksum
4	szip	SZIP compression

Each filter has an optional null-terminated ASCII name and this field holds the length of the name including the null termination padded with nulls to be a multiple of eight. If the filter has no name then a value of zero is stored in this field.

The flags indicate certain properties for a filter. The bit values defined so far are:

Each filter can store a few integer values to control how the filter operates. The number of entries in the Client Data array is stored in this field.

If the Name Length field is non-zero then it will contain the size of this field, a multiple of eight. This field contains a null-terminated, ASCII character string to serve as a comment/name for the filter.

This is an array of four-byte integers which will be passed to the filter function. The Client Data Number of Values determines the number of elements in the array.

Four bytes of zeros are added to the message at this point if the Client Data Number of Values field contains an odd number.