About Metadata

What is metadata?

Metadata means "data about data". For example the date and time that an email message was sent, who it was sent to, and who sent it, are metadata providing a context for, and information about, the text of the message.

Some metadata is readily apparent. The date and time that an email message was sent, who it was sent to, and who sent it, for example, will be shown whenever the email is displayed or printed. Some metadata, for example the last printed date of a Word document, is "hidden" in the sense that it is less well known, only displayed if you tap on certain options, and not so easy to print.

An example in more detail - EXIF metadata

JPGs in EXIF format (“Exchangeable Image File Format”) created by scanning a document also have hidden metadata known as  EXIF tags or "EXIF data". This includes the make and the model of the scanner. In addition XResolution and YResolution give the DPI value. 

JPG photos in EXIF format also have EXIF tags giving the make and model of the camera or phone and have additional EXIF tags such as the exposure time, focal length, and  ISO number, as well as, of course, the date and time that the image was taken. Regarding the date and time of the image, there are, as well as DateTime, two other EXIF date/time tags: DateTimeOriginal and DateTimeDigitized.

As explained in the 2010 report by the Metadata Working Group DateTimeOriginal is the date/time that the camera's image sensor captured the image, DateTimeDigitized is the date/time that the file, containing a digital representation of that image in JPG format, was created on the phone's storage (or SDCard in the case of a digital camera), and DateTime is the date/time that that JPG file was last updated. For modern cameras and phones the difference in time between DateTimeOriginal and DateTimeDigitized is infinitesimal and so they will always be the same down to the second and, providing the JPG has not been changed (e.g. by being rotated by a photo editor), DateTime will be the same as DateTimeOriginal and DateTimeDigitized. 

In addition to those three date/time tags there is, if the device has a GPS sensor and geo-tagging is switched on, GPSDateStamp and GPSTimeStamp which contain the GMT date and time of the GPS satellite signal used for the last GPS fix before the photo was taken. In order to save battery life, if a phone detects that it is stationary (because two consecutive GPS fixes are the same) it will generally stop doing GPS fixes for a period unless and until it detects significant movement (the device can tell when it has started to move from the accelerometer). Consequently at the time a photo is taken the time of the last GPS fix may have been many seconds, or even minutes, before the time the photo was taken but GPSDateStamp/GPSTimeStamp  can, nevertheless, provide useful confirmation that the device's internal clock, which is used when writing DateTimeOriginal/DateTimeDigitized/DateTime, is not wildly wrong.

A phone or digital camera uses its internal clock when writing DateTimeOriginal, DateTimeDigitized, and DateTime. The internal clock of the device can be set to synchronise automatically - with the network signal from the nearest tower in the case of a phone or with the GPS signal in the case of a digital camera - but it can alternatively be set manually. If the internal clock has been set manually it could in theory have been set to the wrong time and/or wrong date. This is more likely to happen with a digital camera than with a phone (because an incorrect date/time on a phone would affect everything - the home screen, emails, and the date shown for SMS messages, for example - and the user would be likely to immediately notice and correct it). Unlike DateTimeOriginal/DateTimeDigitized/DateTime, the GPSDateStamp and GPSTimeStamp tags are not dependent on the device clock - they always show the GMT date/time independently provided by GPS satellites - so if GPSDateStamp/GPSTimeStamp show the same date and approximately the same time as DateTimeOriginal/DateTimeDigitized/DateTime (making allowance for time zone) that provides additional confidence that  DateTimeOriginal/DateTimeDigitized/DateTime are accurate, at least to within a few minutes.

There are other GPS tags present when geo-tagging is switched on. GPSLatitude (together with GPSLatitudeRef showing either North or South) and  GPSLongitude (together with GPSLongitudeRef showing either East or West) will show the approximate location of the camera at the time the photo was taken. The accuracy of the GPS position varies (buildings and terrain may interfere with GPS satellite signals) and there is actually an additional GPS tag which gives an estimate of the degree of horizontal inaccuracy (in metres) - GPSHPositioningError. 

GPSImgDirection is a tag which indicates the direction the camera was pointing when the photo was taken, relative to north (GPSImgDirectionRef identifies whether True or Magnetic north). For example if GPSImgDirection is 186660/2074 that is 90 degrees which is due east. Although the letters GPS appear in this tag it is usually set using data from the device's magnetometer (compass). A GPS signal only needs to be used in the calculation of GPSImgDirection if GPSImgDirectionRef is True (in which case the position of the camera or phone needs to be determined as part of calculating the magnetic declination). 

Metadata "prints" for eBundles

Civil legal proceedings usually end with a final hearing before a judge for which an eBundle (bookmarked PDF) of documents is produced to be seen by the judge and referred to by the parties and their barristers. This means that if either party wishes to rely on "hidden" metadata they will need to take steps to make a "print" or "screenshot" image showing both data and metadata. For example when you view a JPG photo on your phone or computer you would normally initially see the photo image only, but by tapping a "file information" or "properties" option you can then see some of the metadata, including EXIF metadata. A "print" image of the photo would  normally show only the image so if a party wishes to rely on metadata (e.g. to establish when the photo was taken) they have to make a PDF "print" using a suitable viewer program to ensure that the metadata which is to be relied on, as well as the data (the image), both appear in the "print" image or screenshot which will eventually be part of the eBundle.

To allow parties to decide whether they need to rely on metadata (and if so to then produce a "print" image or screenshot showing both data and  metadata to be included in the eventual eBundle) typically the rules of civil courts and other civil tribunals require native copies of documents to be sent by each side to the other at the Disclosure of Documents stage which is normally part way through the legal proceedings. A "native copy" means an exact copy of the file in the same internal format - e.g. a JPG copy of a JPG, or a Word copy of a Word document - which will include all its metadata, or, at least, all embedded metadata. 

Embedded metadata and file-system metadata

The examples of metadata discussed above are examples of embedded metadata specific to the file type - EXIF data in JPG photos, MIME data in emails, and XML data in a Word document - but all files of whatever type will, in addition, have file-system metadata which is maintained by the file system itself (e.g. Windows NTFS or Android Ext4). The file-system metadata maintained for each file will include a "filename" - a series of characters used to uniquely identify the file within a folder on the storage device, often ending with an abbreviation indicating file type, e.g. standardtermsV2.2.pdf

Most file systems allow files to be grouped together in folders, with the possibility of sub-folders so that there is a "pathname" consisting of folder and sub-folder names and ending in the filename. In addition to that, the file system will, of course, record the size of each file. What other file-system metadata there is depends on the particular file system.

On most file systems a "date/time last modified" metadata item is maintained. There may also be a "date/time created" recording the original date/time the file was created. The original idea of file-system date/time metadata was that because these were created automatically by the file system then, as long as the computer clock was correctly set, they must be correct. But it is not so simple if files are transfered from one system to another system. If a file is loaded to a cloud storage system in general only the contents of the file (including embedded metadata) and the filename is retained - other file-system metadata is not retained and the cloud storage system uses the date of upload as the date of the file. If the file is subsequently downloaded the file-system date/time metadata  of the file as downloaded on the target system may refelect the date as recorded in the cloud storage system or it might just be the date/time of the download. If a file is transferred from one system to another using the ZIP, 7-ZIP or RAR file format, an original date/time might be included in the archive file and the receiving system might recognise that metadata and import it so that the file as extracted on the new system has that file-system date/time  (or "date/time last modified" of the file as extracted might be set to that date/time and "date/time created" might be set to the date/time of the import operation). But exactly what the original date/time meant in the exporting system may vary. The exporting system may set and maintain document date/times automatically or dates might be user-defined, particularly if the exporting system is a document management system. Many documents loaded to a document management system are in paper form and are scanned in as PDFs before being loaded so document management systems often allow the user to choose to specify the actual original date of the document, the date on the face of the document, rather than let the date recorded within the document management system default to the date of the PDF scan.

To add to the complexity the built-in version of Extract in Windows 11 File Explorer is known to, in some circumstances when Extracting files from a ZIP file, set "date/time created" on the target system to the "date/time modified" in the ZIP file whilst setting "date/time last modified" on the target system to the date and time of the import!                      

Some file systems also have a "date/time last accessed". As the name suggests, events which will cause the file-system "date/time last accessed" to be updated include many events in which the data is simply read. But in order to be of value a file system has to be somewhat selective about what is to count as an "access". For example if simply displaying the "date/time last accessed" was itself considered to be an "access" then the "date/time last accessed" when displayed would always just show the current date and time! Exactly what counts as an access may vary,  to a degree, between different file systems which maintain this item of metadata.  

Preserving copies of documents with metadata if there are (or may be) legal proceedings  

Although it can depend on the particular tribunal and on any case-specific directions made, the general approach in civil litigation is that there is no expectation that the copies routinely used during the litigation process should have original file-system metadata but, in the event of a query about any specific document, it should be possible for the original document with its file-system metadata to be made available for inspection. For example, if a JPG photo is provided during litigation which has no embedded EXIF data (because it was taken on a very old digital camera, for example) then the original filename might provide a clue as to the date/time taken (if the filename is in yyyyMMdd_hhmmss format). To allow the original file to be inspected if that should become necessary at any point, a copy can be taken at the outset designed to preserve, so far as possible, file-system metadata. So if you made a ZIP or RAR archive of the JPG file at the outset you could, on request, extract a copy of the JPG with original filename. Depending on the programs used to create the archive and subsequently extract files from it, the file system under which the extract program in particular is running, and the history of a file, the "date/time last modified" of a file extracted from the archive might or might not be the original date/time ("date/time created" and "date/time last accessed" probably will not the original in any event) but the filename of the file as extracted should be the original filename (or, at least, the filename as it was at the time the archive was created).       

Different civil courts and other tribunals may have slightly different rules about the disclosure of documents including metadata, and, to a degree, a particular tribunal might give different directions depending on the type of case and the potential significance of particular data. In extreme cases the High Court may make an "imaging order" at an early stage (a compulsory order requiring a party to actual or impending litigation to allow solicitors for another party, accompanied by a neutral "supervising solicitor" and neutral computer expert, to enter premises where computers and other electronic devices belonging to that party are located and take a complete image of each storage medium, the image to be held securely by the computer expert subject to future directions of the court). But, absent such an order, when copies are being taken at the outset - i.e. when the possibility of legal proceedings first arises even before the form of, and forum for, the litigation is considered - the usual approach is to at least make ZIP or RAR archive copies in which at least the original file contents (including embedded metadata), and at least the filename from file-system metadata, is preserved for each file.  

Disclaimer

This information page is designed to be used only by clients of John Antell who have entered into an agreement for the provision of legal services. The information in it is necessarily of a general nature and will not be applicable to every case: it is intended to be used only in conjunction with more specific advice to the individual client about the individual case. This information page should not be used by, or relied on, by anyone else.

The information on this page about specific computer techniques is provided for information purposes only. Every reasonable effort has been made to ensure that the information is accurate and up to date at the time it was written but no responsibility for its accuracy, or for any consequences of relying on it, is assumed by me. You should satisfy yourself, before using any of the techniques, software or services described, that the techniques are appropriate for your purposes and that the software or service is reliable. The features and behaviour of different apps may vary with different versions. Take technical advice as appropriate. 

This page was lasted updated in January 2025. Disclaimer