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. As well as DateTime, there are two other EXIF date/time tags: DateTimeOriginal and DateTimeDigitized. DateTimeOriginal is designed to be filled in to record when the original document being scanned was made, and DateTimeDigitized is when the subsequent scan took place.

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. As explained here 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. In fact, precisely because they are the same, some cameras only fill in one of the three date/time tags. Most cameras set all three but some cameras might just set DateTimeOriginal whilst other cameras might just set DateTime. Programs which display EXIF data sometimes refer to the date/time the image was captured as DateTaken. DateTaken is not actually the name of an EXIF tag but is just a shorthand for "the date/time in whichever of the three date/time EXIF tags has been filled in".   

In addition to DateTaken there is, if the device has a GPS sensor and geo-tagging is switched on, GPSDateStamp and GPSTimeStamp will 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, ago but GPSDateStamp/GPSTimeStamp  can, nevertheless, provide useful confirmation that the device's internal clock, which is used when writing DateTaken is not wildly wrong.

A phone uses its internal clock when writing DateTaken. The internal clock of a phone can be set to synchronise automatically with the network signal from the nearest tower but it can alternatively be set manually. If the internal clock - of a phone or digital camera - 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 soon notice and correct it. Unlike DateTaken 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 DateTaken (making allowance for time zone) that provides additional confidence that  DateTaken is 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).

When you take a photo with a digital camera or phone the rows and columns from the image sensor are stored in a JPG file - first row, written first. Image sensors have a rectangular array - not square - which receives a "landscape" image, where the width is greater than the height, when the phone is being held in its "natural" position for photography - i.e. horizontally. If you want to take a "portrait" photo, where the height is greater than the width, you hold the camera upright - i.e. rotated 90 degrees clockwise from its "natural" position. The phone has a built-in accelerometer which detects how it is being held and it would be possible for the phone software to be designed to transform the series of bits from the sensor so that the first column, rather than the first row, is written first in the JPG when the phone is held upright, so that the image is always written to the JPG file starting with the sky and ending with the ground no matter how it is being held, but that would use up power and slow down the process so, instead, the phone always writes the sensor data in the same way, first row written first, but sets an Orientation tag in the EXIF data within the JPG file it writes to indicate if, and by how much, the image needs to be rotated when being displayed - e.g. 90 degrees clockwise if the phone had been held upright.

The difference between 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 to any embedded metadata, 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

File system metadata

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 initial 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 transferred from one system to another system. Files may be transferred from one system to another for a variety of reasons, for example when one computer is replaced by another or when files are moved to cloud storage to save space. Files on mobile devices such as phones may be copied to a computer as a precaution and subsequently the mobile phone might be lost or destroyed. When files are transferred the original date/time might be retained or, alternatively, it may be reset to the date/time of transfer: it depends on the systems and on how the transfer is accomplished.  

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  

Preserving embedded metadata is straightforward as it is part of the data within each file.

The situation with file-system metadata is more complex. Although it can depend on the particular tribunal and on any case-specific directions given, 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 the original filename of a spreadsheet may give a clue as to what it is a spreadsheet of if that is not otherwise obvious. 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 archive of the spreadsheet at the outset you could, on request, extract a copy of the file with its 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 (any "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 filename as it originally 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 High 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 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 November 2025. Disclaimer