The RIS File Format: Tag Reference, Why Exports Differ, and How to Repair One by Hand

RIS is a plain-text citation interchange format: one record per reference, one field per line, each line opening with a two-character tag. It is what almost every database means by “Export citation” and what almost every reference manager and screening tool means by “Import.” It is also, unusually for something this widely deployed, a format whose specification no longer has a maintained home.

This page does three things that a tag list cannot. It establishes what the normative source for RIS actually is, and where it now lives. It shows, byte for byte, why two exports of the same reference from two different producers do not look alike. And it gives you a reader you can run yourself, so that “this file is broken” and “this repair worked” are things you can demonstrate rather than assume.

What the RIS specification actually is, in 2026

The format takes its name from Research Information Systems, the company behind the Reference Manager application. The specification that later circulated as the canonical one was published on refman.com under ISI ResearchSoft, and every page of it carries the line “This page was last modified on: February 14, 2001.” That document is the source used for every normative claim on this page.

Three things about its current status, each checked directly rather than repeated:

• The original URL no longer serves the specification. http://www.refman.com/support/risformat_intro.asp returns a 301 to https://endnote.com/support/risformat_intro.asp, which in turn lands on Clarivate’s general EndNote support home page at HTTP 200. You get a support portal, not a spec.
• The specification survives in the Internet Archive. The archived overview page carries a table of contents listing fifteen subpages — two on field types and tags, seven of tag definitions, one reference-type list, and five sample records. The Wayback CDX index shows those URLs captured at HTTP 200 in 2001 and returning 301 by 2022. Six were retrieved directly for this page: the overview, the tag-format rules, the title and reference-type tag definitions, the author tag definitions, the year and free-text tag definitions, and the reference-type list.
• Its media type is not registered. Content negotiation for RIS uses application/x-research-info-systems. The x- prefix is a clue, and the registry confirms it: IANA’s media types registry for the application tree contains 1,795 registered subtypes and none of them matches “research-info”.

So: when a page presents a RIS tag table, ask where the table came from. Community tag lists on wikis and vendor help pages are useful, and several are more current than the 2001 document, but none of them is normative, and at least one widely-copied claim in circulation contradicts the original spec outright (see the AB/N2 trap below). Treat the archived ISI ResearchSoft pages as the historical authority, treat each producer’s own documentation or source code as authoritative for that producer, and treat everything else as description.

The tag format, exactly as specified

The 2001 specification is unusually precise about the shape of a line. Each field is preceded by a six-character label:

1. Character 1 — uppercase alphabetic, specific to the field type
2. Character 2 — uppercase alphabetic or numeric
3. Characters 3 and 4 — spaces (ANSI 32)
4. Character 5 — dash (ANSI 45)
5. Character 6 — space (ANSI 32)

In other words TY  - , with two spaces before the dash and one after it, is the specified form. Not one space. This single detail causes more failed imports than any other, because it is invisible in a text editor.

On record structure the spec is equally direct: “the required tags are ‘TY’ which must be the first tag in the reference, and ‘ER’ which must be the last tag in the reference. Other tags can be in any order.” That is the whole grammar. Everything else — which tags a record carries, in what sequence — is producer choice.

Which means the smallest well-formed RIS record is two lines:

TY  - JOUR
ER  - 

That is not a useful record, but it is a structurally valid one, and it is worth knowing that the format imposes no other mandatory field. There is no required title, no required author, no required date. Any expectation beyond TY and ER belongs to the importing application, not to the format.

A reader you can run

Rather than assert what a conformant reader does, here is one, written directly from the five tag-format rules above. It is deliberately strict: exactly two spaces, uppercase tags, TY first, ER last. Note that it uses character codes rather than escape sequences for CR and LF, which makes the line-ending handling explicit — that turns out to matter (see the producer comparison).

// ris-file-format-parser.mjs - a strict RIS reader built from the 2001 tag-format rules
const CR = String.fromCharCode(13);
const LF = String.fromCharCode(10);

// Tag format per the original spec: char 1 uppercase alpha, char 2 uppercase
// alphanumeric, chars 3-4 spaces, char 5 dash, char 6 space.
const TAG_LINE = /^([A-Z][A-Z0-9])  - ?(.*)$/;

function splitLines(text) {
  return text.split(LF).map(l => (l.endsWith(CR) ? l.slice(0, -1) : l));
}

function parseRecord(text) {
  const errors = [];
  const fields = [];
  const lines = splitLines(text).filter((l, i, a) => !(l === '' && i === a.length - 1));
  let seenER = false;

  lines.forEach((line, i) => {
    const m = line.match(TAG_LINE);
    if (m) {
      if (seenER) errors.push('line ' + (i + 1) + ': tag ' + m[1] + ' appears after ER');
      if (fields.length === 0 && m[1] !== 'TY')
        errors.push('line ' + (i + 1) + ': first tag is ' + m[1] + ', spec requires TY first');
      if (m[1] === 'ER') seenER = true;
      fields.push({ tag: m[1], value: m[2] });
    } else if (line.trim() === '') {
      // blank line between records - ignore
    } else if (fields.length > 0) {
      fields[fields.length - 1].value += ' ' + line.trim();   // continuation
      errors.push('line ' + (i + 1) + ': continuation folded into ' + fields[fields.length - 1].tag);
    } else {
      errors.push('line ' + (i + 1) + ': not a tag line and no field to continue: ' + JSON.stringify(line));
    }
  });

  if (!fields.some(f => f.tag === 'TY')) errors.push('record has no TY tag');
  if (!seenER) errors.push('record has no ER tag - reader cannot know where it ends');
  return { fields, errors };
}

One honest limitation, visible in the output below: parseRecord reads a single record. A real file holds many, and the splitter is the ER line. Feeding it a two-record file produces exactly the diagnostic you would expect.

Constructing a broken record, and repairing it

Here is a record typed by hand with the three mistakes people actually make: one space instead of two on the first line, a title wrapped by hand across two lines, and no ER at the end.

TY - JOUR
AU  - Heim,S.K.
TI  - A short title that someone
wrapped by hand
PY  - 1998///Spring
VL  - 12

Run through the reader above, alongside the repaired version and the two-line minimal record, the actual console output is:

--- hand-typed, broken ---
tags parsed : AU TI PY VL
notes       : line 1: not a tag line and no field to continue: "TY - JOUR" | line 2: first tag is AU, spec requires TY first | line 4: continuation folded into TI | record has no TY tag | record has no ER tag - reader cannot know where it ends
VERDICT     : REJECTED (4)

--- same record, repaired ---
tags parsed : TY AU TI PY VL ER
notes       : none
VERDICT     : ACCEPTED

--- minimal record the spec allows ---
tags parsed : TY ER
notes       : none
VERDICT     : ACCEPTED

Read the first block carefully, because it shows how a single-character error cascades. The malformed TY - JOUR line does not merely lose the reference type; because it is not recognised as a tag line at all and there is no preceding field to continue, it is discarded, the record then appears to begin at AU, and the reader reports a missing TY. A person looking at this file in a text editor sees a TY line right there at the top and concludes the importer is broken.

The failure with no visible symptom at all

A UTF-8 byte order mark in front of the first tag produces the same cascade, and unlike a missing space it is invisible in every editor:

--- file saved with a UTF-8 BOM ---
tags parsed : TI ER
notes       : line 1: not a tag line and no field to continue: "TY  - JOUR" | line 2: first tag is TI, spec requires TY first | record has no TY tag
VERDICT     : REJECTED (3)

--- same file, BOM stripped ---
tags parsed : TY TI ER
notes       : none
VERDICT     : ACCEPTED

--- file with leading blank lines ---
tags parsed : TY TI ER
notes       : none
VERDICT     : ACCEPTED

--- two records concatenated (parsed as one) ---
tags parsed : TY TI ER TY TI ER
notes       : line 5: tag TY appears after ER | line 6: tag TI appears after ER | line 7: tag ER appears after ER
VERDICT     : REJECTED (3)

The BOM case is the one worth remembering. It appears whenever a file has been opened and re-saved in a Windows editor set to “UTF-8 with BOM.” Leading blank lines, by contrast, are harmless.

Repairing a broken export by hand

Work down this list in order. Every item is a failure mode demonstrated above or observed in the real exports in the next section.

1. Open the file in an editor that shows invisible characters and can save as UTF-8 without a BOM. This is the whole game; most RIS damage is whitespace and encoding, not content.
2. Check character 3 and 4 of every tag line. Two spaces, then the dash, then one space. A file that has been through a spreadsheet, a word processor, or a copy-paste through a web form frequently has one space, or a tab, or a non-breaking space.
3. Confirm the first tag of each record is TY and the last is ER. If a file was truncated mid-download the final record will have no ER; append one. If two files were concatenated, make sure there is a line break after each ER.
4. Re-join hand-wrapped lines. A continuation line is legal, but it is only unambiguously a paragraph break inside a free-text field. Anywhere else, folding it back into the preceding field is what a reader will do, and it is what you want.
5. Normalise line endings before you normalise anything else. Mixed CR-LF and LF in one file is common when records have been assembled from two sources.
6. Strip anything before the first TY — HTTP headers, an HTML error page, an editor’s BOM. A surprising number of “corrupt RIS” files are actually a saved error page.
7. Re-run a reader over the repaired file and require it to accept. Do not eyeball it. The BOM case above is the proof that eyeballing does not work.

Why two exports of the same format do not match

This is the part most RIS pages leave out, and it is the part that determines whether a bulk import will be clean. The comparison below uses DOI content negotiation, which returns RIS for any registered DOI and routes to whichever registration agency owns the prefix — so it isolates the producer while holding the format constant. Both files were retrieved with Accept: application/x-research-info-systems and inspected byte by byte.

Crossref, for a journal article:

TY  - JOUR
DO  - 10.1038/nphys1170
UR  - http://dx.doi.org/10.1038/nphys1170
TI  - Measured measurement
T2  - Nature Physics
AU  - Aspelmeyer, Markus
PY  - 2009
DA  - 2009/01
PB  - Springer Science and Business Media LLC
SP  - 11-12
IS  - 1
VL  - 5
SN  - 1745-2473
SN  - 1745-2481
ER  - 

DataCite, for a software deposit (abstract and keyword lines truncated here for width; the file itself is 1,627 bytes):

TY  - COMP
T1  - BGC-val: a model and grid independent python toolkit ...
AU  - De Mora, Lee
AU  - Yool, Andrew
AU  - Popova, Ekaterina
AU  - J. Icarus Allen
DO  - 10.5281/ZENODO.1215934
UR  - https://zenodo.org/record/1215934
AB  - The BGC-val model evaluation suite. This is a python toolkit ...
KW  - Biogeochemical Model
PY  - 2018
PB  - Zenodo
LA  - en
ER  - 

Both parse cleanly. The reader above accepts both:

=== Crossref export, as delivered ===
bytes 288 | line breaks 15 | of which CRLF 0
tags parsed : TY DO UR TI T2 AU PY DA PB SP IS VL SN SN ER
VERDICT     : ACCEPTED

=== DataCite export, as delivered ===
bytes 1627 | line breaks 21 | of which CRLF 21
tags parsed : TY T1 AU AU AU AU AU AU AU AU DO UR AB KW KW KW KW KW PY PB LA ER
VERDICT     : ACCEPTED

And yet almost nothing about them is the same. The differences below are the ones that actually cost you data on import.

Behaviour	Crossref	DataCite
Primary title tag	TI	T1
Line terminator	LF throughout (0 CRLF in 15 breaks)	CR-LF throughout (21 of 21 breaks)
Terminator after the ER line	LF present	none — the file ends on ER - with a trailing space and no line break
DOI case	preserved as registered	suffix upper-cased (ZENODO)
Abstract	not emitted	AB
Keywords	not emitted	KW, one per line
Journal / container	T2	n/a
Date	PY and DA both, DA as 2009/01	PY only
Pages	SP - 11-12 — a full range inside the start-page tag, no EP	n/a
ISSN	SN twice, print and electronic, unlabelled	n/a
Author name form	Family, Given	Family, Given for seven authors, natural order (J. Icarus Allen) for the eighth

Several of these are worth dwelling on. The trailing-terminator difference means a naive script that concatenates two DataCite exports produces a file whose second record begins on the same line as the first record’s ER. The page-range-in-SP behaviour means a consumer that expects SP and EP will store “11-12” as a start page. The double SN means a consumer that maps SN to a single ISSN field silently keeps whichever it saw last. And the mixed author name forms inside one file mean no single parsing rule for AU is safe: a comma-splitting rule turns “J. Icarus Allen” into a one-part name, while a whitespace rule mangles the other seven.

The lesson is not that one producer is wrong. Both files conform to the grammar. The format simply does not constrain any of this, so the burden falls entirely on the importer — which is why the same file can import cleanly into one reference manager and badly into another.

The AB / N2 trap

This is the single most consequential divergence in RIS, and it is one where the widely-copied community guidance contradicts the original specification.

The 2001 tag definitions state it plainly. Under Tag Definitions: Year and Free Text Fields:

• N1 and AB — Notes. “These are free text fields and can contain alphanumeric characters; there is no practical length limit to this field.”
• N2 — Abstract. “This is a free text field and can contain alphanumeric characters; there is no practical length limit to this field.”

So in the normative document, AB is an alias for the notes field and N2 is the abstract. In practice the opposite convention won. DataCite, in the export above, emits the abstract under AB. Zotero’s RIS translator, whose source is public and is authoritative for Zotero’s own behaviour, resolves it in both directions: its primary field map assigns AB to the abstract and N1 to notes, while a secondary map for non-canonical tags additionally assigns N2 to the abstract.

Practically, that means:

• If your file uses AB for the abstract, most modern importers do what you intend, and a strictly spec-conformant one files it as a note.
• If your file uses N2 for the abstract, most modern importers still do what you intend, because they accommodate both.
• If your file genuinely carries a note in AB, as the spec provides for, a modern importer will file it as the abstract. This is the direction that loses data quietly, and it is the reason to prefer N1 for notes.

Any tag table that lists AB as “Abstract” with no further comment is describing current practice, not the specification, and is not telling you that the two disagree.

Author names, and why they arrive scrambled

The spec is specific here too. A1 and AU both carry Author Primary; A2 and ED carry Author Secondary; A3 carries Author Series. Each author must be on its own line with its own tag, and the name syntax given is:

Lastname,Firstname,Suffix

with the spec’s own worked examples written without a space after the comma — Heim,S.K., Heim,Susan Kay, Heim,Susan K., and Kenney,N.B.,Jr. for the optional suffix. The stated limits are up to 255 author fields per reference and up to 255 characters per field.

Neither real export above follows that punctuation. Both emit Family, Given with a space, and DataCite emits one of eight authors in natural order with no comma at all. If you are repairing an export by hand, converting every AU line to Lastname,Firstname is the safest normalisation, because it is the one form every importer was originally built to read.

Dates: the slashes are not optional

The spec assigns Y1 and PY to Date Primary and Y2 to Date Secondary, with a fixed shape:

YYYY/MM/DD/other info

Year, month and day are numeric; the fourth component is any string of letters, spaces and hyphens. The specification’s own note is the part people miss: “each specific date information is optional, however the slashes are not.” Its example of a year plus a season is 1998///Spring — three slashes, two empty components.

Modern producers mostly ignore this. Crossref emits a bare PY - 2009 and a separate DA - 2009/01; DataCite emits PY - 2018 and no DA at all. Both are fine for importers that parse leniently, which is all of them. But if you are hand-writing a record for an older tool, the padded form with its empty slots is the one the spec describes.

The TY vocabulary has drifted

The 2001 specification lists 35 reference-type codes for the TY field: ABST, ADVS, ART, BILL, BOOK, CASE, CHAP, COMP, CONF, CTLG, DATA, ELEC, GEN, HEAR, ICOMM, INPR, JFULL, JOUR, MAP, MGZN, MPCT, MUSIC, NEWS, PAMP, PAT, PCOMM, RPRT, SER, SLIDE, SOUND, STAT, THES, UNBILL, UNPB and VIDEO.

Zotero’s exporter writes 28 codes. Comparing the two lists directly gives:

2001 spec reference types      : 35
codes Zotero exports           : 28
Zotero codes NOT in 2001 list  : BLOG, DICT, ENCYC, MANSCPT
2001 codes Zotero never writes : ABST, ADVS, CTLG, GEN, INPR, JFULL, MUSIC, PAMP, SER, UNBILL, UNPB

Four codes in current use were invented after the specification stopped being maintained, and eleven specified codes have effectively fallen out of use. Note also what DataCite did with a software deposit above: it chose COMP, the 1990s “Computer program” type, because the vocabulary has no code for a software release. If your import produces a pile of items typed “Generic,” an unrecognised TY code is the usual reason.

Readers disagree about what is valid

There is no conformance test suite for RIS, so “valid” means “accepted by the tool in front of you.” Zotero’s translator source defines its tag line as the regular expression /^([A-Z][A-Z0-9]) {1,2}-(?: (.*))?$/ — note {1,2}, which accepts one or two spaces before the dash, and the optional value group, which accepts a tag with no value at all. Running the same candidate lines against that rule and against the spec-strict rule used earlier:

"TY  - JOUR"   spec-strict: match   Zotero rule: match
"TY - JOUR"    spec-strict: NO      Zotero rule: match
"ty  - JOUR"   spec-strict: NO      Zotero rule: NO
"T1  - Title"  spec-strict: match   Zotero rule: match
"ER  - "       spec-strict: match   Zotero rule: match
"ER  -"        spec-strict: match   Zotero rule: match

The second row is the whole problem in one line. A one-space file imports into Zotero and fails elsewhere, so “it works in my reference manager” is not evidence the file is well-formed. Two further differences in strictness worth knowing, both from the same source: Zotero treats a continuation line as a genuine paragraph break only inside AB, N1, N2 and RN, and it guesses whether a wrap was hard or soft from the file’s maximum line length; and it preserves line breaks as separators inside KW, L1, L2 and L3. Its export side writes CR-LF, with the source comment “from spec.”

Producer-specific tags you will encounter

Because there is no registry of tags, producers added their own. Zotero’s translator carries a map for non-canonical tags with the originating tool annotated in comments — a useful field guide to what you are looking at:

• M3 carrying a DOI, rather than DO. If a DOI seems to have vanished on import, check M3 first.
• M1 carrying the issue number for a journal article, annotated in the source as an EndNote behaviour, and carrying the number of volumes for a book section “instead of IS”.
• M2, annotated simply “not in spec”.
• CY used for place on conference papers, annotated as ProCite and Springer behaviour where C1 would be expected.
• H1 and H2, annotated as Citavi-specific, carrying library catalog and call number.
• AV for archive location, annotated as a Reference Manager tag.
• JO, JF and JA all carrying some form of journal name, with JO meaning the abbreviation in most contexts and the conference name on a conference paper.
• BT, which maps to the primary title for whole books and unpublished works and to the secondary title for everything else — a genuinely context-dependent tag, and that ambiguity is in the 2001 spec itself, not a later invention.

RIS, BibTeX and CITATION.cff are not interchangeable

RIS is one of three plain-text citation formats a researcher meets regularly, and they solve different problems.

• RIS is line-oriented and flat. One tag, one line, no nesting, no quoting or escaping mechanism of any kind. That is why a stray line break is fatal and why there is no way to put a literal line break inside a field except by relying on the reader’s continuation heuristic. It is optimised for exchange between reference managers and for bulk import into screening tools — see Covidence, Rayyan and DistillerSR compared, all of which take RIS as their primary import path.
• BibTeX is brace-delimited, has typed entries and a citation key, and inherits LaTeX’s escaping rules — which is both its strength (you can protect capitalisation, express accents portably) and its weakness (there are real encoding traps). It is a typesetting input format first and an interchange format second. Our guide to getting clean BibTeX from a DOI documents specific defects in machine-generated BibTeX — en dashes in page ranges, missing capitalisation braces — that have no RIS equivalent, precisely because RIS has no escaping layer to get wrong.
• CITATION.cff is a YAML schema for citing software, with a defined specification and a validator. See Citation File Format (CITATION.cff). Where RIS was retrofitted to software by reusing the 1990s COMP type, CFF was designed for it.

Converting RIS to BibTeX is lossy in a specific way worth naming: the producer-specific tags above have no BibTeX counterpart, and RIS carries no citation key, so one has to be invented. Converting the other direction loses BibTeX’s brace-protected capitalisation, because RIS has nowhere to put it.

Working with RIS in practice

A few operational points that follow from everything above.

• Deduplicate after import, not before. Because producers differ on title tag, author punctuation and DOI case, string-matching two RIS files against each other before import will miss duplicates that a reference manager, working on parsed fields, catches easily. The 10.5281/ZENODO.1215934 versus 10.5281/zenodo.1215934 case above is exactly this.
• For a systematic review, keep the raw exports. PRISMA reporting needs per-database record counts, and the raw RIS file is the primary evidence for them. See PRISMA and systematic review methodology and, for the search side, Boolean search operators for literature searching.
• Prefer content negotiation over a website’s export button when you have a DOI and want something reproducible. A single request with an Accept header returns RIS from the registration agency directly, which is scriptable and gives you the same bytes every time. Both examples on this page were obtained that way. Related: Crossref REST API and DataCite Metadata Schema.
• Do not hand-edit a file you have not first run through a reader. Every hand repair risks introducing the one-space or BOM failure above.

For reference-manager-specific import and export behaviour, see Zotero for researchers, Zotero setup and troubleshooting, how to use EndNote, and RefWorks. This page sits in CASRAI’s research tools and software cluster alongside them.

Common questions

What does .ris stand for?

Research Information Systems — the company that created the format for its Reference Manager application, not a description of the file’s contents. The media type used for it, application/x-research-info-systems, spells the name out.

What tags are required in a RIS file?

Exactly two, per the specification: TY as the first tag of a record and ER as the last. Nothing else is mandatory at the format level. Any other requirement — a title, an author, a year — comes from the application you are importing into.

How do I open a .ris file?

It is plain text, so any text editor will show you its contents. To use it as a citation, import it into a reference manager rather than opening it: in Zotero, EndNote, Mendeley or RefWorks the action is File then Import, pointing at the .ris file. If you only need to read it, an editor is both sufficient and safer, because it will not silently re-save the file with a BOM.

Why did my RIS import lose the abstracts?

Most likely an AB versus N2 mismatch. The original specification defines AB as a notes field and N2 as the abstract; current practice has largely reversed that. Check which tag your source used and which your destination expects — see the AB/N2 trap above.

Why do the same references look different when exported from two databases?

Because the format constrains almost nothing beyond the line shape and the TY/ER bookends. Which tags to emit, how to punctuate author names, whether to use TI or T1, whether to split page ranges across SP and EP, and which line ending to use are all producer choices. The side-by-side comparison above shows ten such differences between two exports that both parse cleanly.

Is RIS an official standard?

No. It is a vendor format that became a de facto interchange convention. Its media type is not registered with IANA, and the specification’s original home now redirects to a general product support page. That is different from the situation for bibliographic reference style, which does have a standard — see NISO Z39.29 — and different again from CITATION.cff, which has a maintained specification and a validator.

Can I convert RIS to BibTeX losslessly?

Not in general. RIS has no citation key, so one must be generated, and producer-specific tags such as M1, M2, H1 and AV have no BibTeX counterpart. Going the other way loses BibTeX’s brace-protected capitalisation. If you have a DOI, requesting each format directly from the registration agency is cleaner than converting between them.

Should a RIS file use CR-LF or LF line endings?

Both are found in the wild and both work with mainstream importers — Crossref delivers LF, DataCite delivers CR-LF, and Zotero’s exporter writes CR-LF with a source comment attributing that choice to the spec. What causes trouble is mixing them within one file, which happens when records from two sources are concatenated. Normalise to one before importing.

What this page does not assert

In the interest of being clear about the limits of what was checked:

• The specification pages cited here were retrieved from Internet Archive snapshots of refman.com, all page-dated 14 February 2001 and copyright ISI ResearchSoft. The pages actually retrieved and used were the overview, the tag-format rules, the title and reference-type tag definitions, the author tag definitions, the year and free-text tag definitions, and the reference-type list. The misc-tags page could not be retrieved during this work, so nothing is claimed about its contents — in particular, nothing is claimed here about whether the 2001 document defines a DO tag.
• The claim that RIS exists in more than one version, with a later revision adding header information, is reported in secondary sources and not verified here. Only the 2001 document was examined.
• Statements about Zotero’s behaviour come from reading its public RIS translator source, which is authoritative for Zotero and for nothing else. Statements about EndNote, ProCite, Springer and Citavi tag usage are reproduced as annotations in that source and were not independently confirmed against those products.
• “Not an official standard” is supported here by a verified absence from the IANA media types registry and by the loss of the specification’s maintained home. No exhaustive search of every standards body was performed.
• The two exports compared are one journal article and one software deposit, retrieved on 26 August 2026. They demonstrate that producers differ; they are not a survey of how every producer differs.