# Relativity Load File OCR Text: What an Import Needs

- Author: Schema Law (https://www.schemalaw.com/)
- Published: 2026-08-15T16:11:41Z
- Updated: 2026-10-11T19:22:20Z
- Category: Litigation support
- Canonical: https://www.schemalaw.com/blog/relativity-load-file-ocr

> What a Relativity load file needs from OCR: text for every scanned document, a path column that finds it, a known encoding, and a check for empty fields.

A Relativity load file needs one thing from your OCR output: the text of every document, tied to that document's identifier. You supply it inside a long text field of the load file or as one text file per document with a column that gives each file's path. Relativity's own documentation describes both routes.

Everything else in the load is bookkeeping around that text. The details below come from Relativity's published documentation for Server 2024 and RelativityOne, which differ in places. Check the pages for the version your workspace runs, and ask whoever administers it before you build a volume. Schema Law has no connection to Relativity. Its part ends at the text files.

## What does a Relativity load file need from OCR?

A Relativity load file needs the recognized text of each scanned document, matched to a unique identifier, in a form the importer can map to a long text field. Relativity's documentation calls that field Extracted Text and says it holds "the text of the document. Either the OCR or Full Text."

The same passage in Relativity's [load file specifications for Server 2024](https://help.relativity.com/Server2024/Content/Relativity/Relativity_Desktop_Client/Importing/Load_file_specifications.htm) explains why the field matters: "The extracted text appears in the viewer and is added to search indexes." A scanned letter that loads with an empty text field still opens as an image. It simply never answers a search.

For a paper collection, the load therefore has three working parts:

| Part | What it is | Where OCR comes in |
| --- | --- | --- |
| Identifier | A unique value per document, usually a control number or first Bates number | The text file is named after it |
| Text | The words of the whole document, all pages in order | This is the OCR output |
| Path or field | The column that tells the importer where the text is | Must match the folder you build |

Relativity states that "the identifier field is required for each load" and describes the file as "a flat, document-level load file" in which "each line should represent one document". That last phrase sets the unit for your OCR. A 40-page contract is one row and one body of text. It is not 40 rows.

Two consequences follow for anyone converting scans.

**Text is per document.** If your scans came off the copier as one long PDF per box, split them into documents before you run OCR, so each export covers exactly one row of the load file.

**Text follows the produced page.** If a page was redacted or stamped after the first OCR pass, the text you load should come from the final image. Text made from an earlier version can contain words the image no longer shows.

The layout of the data file itself, with its delimiters and header row, is explained in the post on [what is inside a DAT file](https://www.schemalaw.com/blog/concordance-load-file#what-is-inside-a-dat-file).

## Extracted text files and the path column in a Relativity import

Relativity accepts OCR text in two forms. The Extracted Text column can hold the words themselves, or it can hold the path to a text file containing them. In the second form the importer reads each path, opens the file, and loads its contents into the long text field you mapped.

The specification lists the two options as "the actual OCR or Full Text" and "the path to a document level text file containing the OCR or Full Text." For scanned paper, the path form is the easier one to get right. Page after page of recognized text inside a delimited file means every stray delimiter character and every line break has to be escaped, and one failure shifts the rest of the row.

Point the extracted text path at a file you have already opened and checked. In a Relativity load, that path is what places words in the viewer and in the search index. A production image with an empty text field still opens, and nobody can search it. Load a small sample, search a Bates number and a word from the page, then load the rest of the electronically stored information.

### Telling the importer the column is a path

The importer has to be told which form you used. In the Relativity Desktop Client, the setting is a checkbox described in the guide to [importing document metadata, files and extracted text](https://help.relativity.com/Server2024/Content/Relativity/Relativity_Desktop_Client/Importing/Importing_document_metadata__files__and_extracted_text.htm). The option is named "Cell contains file location", and the guide says to select it "if your extracted text is in document-level text files, and your load file contains a path to those text files." The same page notes that "you can import full text or OCR into any long-text field that has been mapped", so the text does not have to land in the field named Extracted Text.

With that option off, the importer has no reason to treat the cell as anything but text. The risk is a workspace where each document's text reads `TEXT\001\ABC0000001.txt`, so look for exactly that after a test load.

### Writing the paths

Relativity's Server 2024 specification says "both relative and absolute paths are supported" and asks for Windows-style formatting with backslashes. The [Import/Export load file specifications for RelativityOne](https://help.relativity.com/RelativityOne/Content/Relativity/Import_Export/Import_Export_Load_file_specifications.htm) add a condition: "to import load file data that contains absolute paths, you must activate Express Transfer." They also show the accepted shapes of a relative path, which "can start with Blank or .\".

Relative paths are the safer habit in either version. A path that begins with your own drive letter stops working the moment the volume moves to another machine.

A three-document example, shown with a pipe between columns for readability:

```
CONTROLNUMBER | PGCOUNT | EXTRACTEDTEXT
ABC0000001    | 3       | TEXT\001\ABC0000001.txt
ABC0000004    | 1       | TEXT\001\ABC0000004.txt
ABC0000005    | 12      | TEXT\001\ABC0000005.txt
```

The header names are yours to choose. RelativityOne's specification says header rows are not required but "strongly recommended to ensure accuracy", and that "the field names in your header do not need to match the field names in your workspace." You match them by hand during the load. If the load file is going to someone else, their field list governs, which is the subject of the post on [matching a custom load file specification](https://www.schemalaw.com/blog/custom-load-file-ocr).

## Does Relativity run OCR itself after import?

Relativity's documentation describes no OCR step in a load file import. The load brings in the text you supply. The documentation covers two separate OCR routes: a setting in the processing profile that applies when Relativity processes native files, and an OCR job that a user sets up inside the workspace after documents are imaged.

Each route answers a different question, so take them one at a time.

**Load file import.** The import guide describes mapping columns to fields and loading text from a field or a file. It mentions no recognition step, so plan on a row with an empty text column staying empty until someone adds text.

**Processing.** When files go through Relativity Processing instead of a load file, the [processing profile documentation for RelativityOne](https://help.relativity.com/RelativityOne/Content/Relativity/Processing/Processing_profiles.htm) describes an OCR field: "select Enable to run OCR during processing. If you select Disable, Relativity won't provide any OCR text in the Extracted Text view." The same page adds a caution in Relativity's own words: "OCR performed during processing is not intended to be a complete replacement for imaging and OCR features available post-publish in the workspace."

**OCR in the workspace.** Relativity's [OCR documentation for RelativityOne](https://help.relativity.com/RelativityOne/Content/Relativity/OCR/OCR.htm) sets out three steps: define a production or saved search containing the documents, create an OCR profile, and create an OCR set that uses the profile. It states that "all documents, including native files, must be imaged before using OCR." Results go to a destination field you choose.

One sentence on that page deserves a second read if you loaded your own text. Of the destination field it says: "This field is overwritten each time a document is OCRed with that destination field selected." Pointing a later OCR set at the field that holds your imported text replaces it for those documents. If you want both versions, ask your administrator about a separate long text field for one of them.

So should you OCR first? If you are building a load file for scanned documents, yes, because the load file is where the text travels. If the documents are going into a workspace you control and your administrator plans to image them and run an OCR set, you may not need to. That is a conversation to have before you spend a day on text files. Platforms that take a plain upload and handle recognition on intake are compared in the post on [OCR before uploading to a review platform](https://www.schemalaw.com/blog/ocr-before-uploading-to-a-review-platform).

## Encoding and line endings for Relativity text files

Relativity's documentation asks for a known encoding and says nothing about line endings in separate text files. Save every text file in one encoding, prefer UTF-8 with a byte order mark so the importer can detect it, and keep whatever line breaks the OCR export wrote.

### Encoding

The Server 2024 specification explains how detection works in the Desktop Client: it "checks the byte order mark at the beginning of the file", and "if there is no byte order mark, it cannot determine the encoding type." The marks it recognizes are listed as Unicode (UTF16), Big-Endian Unicode and UTF8. A file without one is "considered undetectable" and takes "the default encoding chosen for the load file or stand-alone extracted text file."

That default is the import setting called "Encoding for undetectable files", whose options include Western European (Windows), Unicode and Unicode (UTF-8). RelativityOne's Import/Export specification puts the duty on you more bluntly: "You must choose the proper encoding of a file when a load file is first selected."

Why does this matter for OCR text in particular? Recognized text is full of characters outside plain ASCII: curly quotation marks, section signs, accented names, the degree sign in a lab report. If a UTF-8 file with no byte order mark is read as Western European, each of those becomes two or three wrong characters. "Peña" turns into something no search for Peña will find. The words around it still look fine, which is why the damage goes unnoticed.

A workable rule:

- Pick one encoding for the whole volume and write it in your notes.
- If the tool that made the text files does not add a byte order mark, set the import's fallback encoding to match what the files really are.
- After a test load, search for a name with an accent or a document with a section sign and look at how it displays.

### Line endings

Relativity's delimiter list includes a Newline character, code 174, which the specification says "marks the end of a line in any extracted or long text field". That character applies to text placed inside the load file. It stands in for a real line break there, because a real one would end the record. It does not apply to a separate text file, which keeps ordinary line breaks.

The Relativity pages cited here do not state whether those ordinary breaks should be the Windows pair of carriage return and line feed or a single line feed. Text files made on Windows usually use the first and files made on a Mac or Linux use the second. If your test load shows text running together with no breaks, convert the files to Windows line endings in a text editor and load again.

## Turning OCR exports into a Relativity-ready text folder

Run OCR on one PDF per document, export plain text, name each text file after the document's identifier, place the files in a folder beside the load file, and write each file's relative path into the text column. The procedure is short. The discipline is in the names.

1. **Fix the identifiers first.** Decide the control number or Bates number for every document before any OCR. Renaming afterwards is where pairs get crossed.
2. **Name each PDF after its identifier.** `ABC0000001.pdf`, with leading zeros, no spaces.
3. **Run OCR and export plain text.** In Schema Law you upload a PDF, PNG or JPEG of up to 20 MB in the browser, look over the parsed pages, and choose the plain text export. Each uploaded document gives you one text file. Plain text is included on every plan, though the free plan stops at three pages per document.
4. **Rename the export to match.** `ABC0000001.txt`. Do this as each file downloads, not at the end.
5. **Build the folder.** A `TEXT` folder at the top of the volume, with subfolders if the count is large.
6. **Fill the path column.** One relative path per row, backslashes, exactly as the file sits on disk.
7. **Confirm the encoding** of a few files in a text editor and record it.
8. **Count.** Rows in the load file, PDFs and text files should be three equal numbers.

A finished volume for documents ABC0000001, ABC0000004 and ABC0000005:

```
VOL001\
  VOL001.dat
  TEXT\001\ABC0000001.txt
  TEXT\001\ABC0000004.txt
  TEXT\001\ABC0000005.txt
```

Images or native files travel in their own folders with their own columns, which this post leaves aside.

Be clear about where the OCR tool stops. Schema Law's plain text, searchable PDF and other exports, listed under [export formats on the home page](https://www.schemalaw.com/#formats), are ingredients. None of them is a load file, and nothing in the product sends files to Relativity. Schema Law does not produce load files on any plan. The plans on the [pricing page](https://www.schemalaw.com/pricing) differ in price, page allowance and support, not in what the software exports. The table of documents and paths is something you assemble yourself.

## Checking a Relativity import for empty text fields

After the load, look for documents whose text field is empty or suspiciously short, then open a sample and compare the text with the image. An import can finish cleanly and still leave scanned documents unsearchable, because an empty text value is valid data.

### Before you import

The cheapest checks happen on your own machine.

- Sort the text folder by size. A file of zero bytes, or a few bytes, belongs to a document where recognition found nothing. Open the PDF and see whether that is right. A photograph should be empty. A typed letter should not.
- Compare the list of text file names with the identifier column. Every row needs a file and every file needs a row.
- Use the importer's own preview. Relativity's import guide describes a Preview Errors option that "checks all documents for potential loading errors, but displays only the first 1000 errors", and says Relativity "includes the functionality for previewing the import file as well as the encoding of the extracted text files."

### After you import

How you list empty-text documents depends on how your workspace is set up, so ask your administrator for a search or view that shows the text field's size. Then work through this list.

1. **Empty text.** Any document from your scanned set with no text at all. Trace each to its text file.
2. **Path as text.** Search for `.txt` or for your folder name. Hits mean the path was loaded as the text itself.
3. **Wrong text.** Open ten documents at random and read the first line of text against the first line of the image. A mismatch across many documents means the names slipped by one.
4. **Broken characters.** Search for a string such as `Ã` that appears when UTF-8 is read as Western European.
5. **Thin text.** A 30-page document with 200 characters of text was recognized badly, whatever the load report says.

Fix problems in the source files and reload those rows. Relativity's import guide describes an "Overlay Only" mode that "updates existing records only", using an identifier to find them. That lets you correct text without loading the documents a second time, provided the overlay file carries the same identifiers.

None of these checks says whether the words are right. They only tell you that text exists and belongs to the right document. For how recognition goes wrong on names and numbers, and how to sample for it, see the post on [why OCR output is full of errors](https://www.schemalaw.com/blog/why-is-ocr-output-full-of-errors).

## Try it on a real document

Upload a scanned PDF and export it as Word, a searchable PDF or plain text on the free plan. Your documents are never used to train an AI model. [Start free](https://www.schemalaw.com/api/auth/google)