Curator Guide

Welcome curators! This guide describes some of the curatorial tools iNat provides as well as some of iNaturalist's policies toward how we curate our taxa. If you're not a site curator and would like to help curate our taxa, please contact us. We will generally allow anyone to be a curator if we know they have some expertise, or if they've demonstrated expertise by using the site. If you would like to be a curator but we don't know you and you have zero observations or identifications, we will probably ask you to use the site a bit more before approving your request. If you demonstrate by your behavior on the site or through your communication to us (the site admins) that you are unwilling to abide by our curatorial policies, abusive to us or members of our community, or otherwise unreasonable, we will revoke your curator status, or just not grant it in the first place. What constitutes abusive or unreasonable behavior is at the discretion of the site admins.

Being a site curator means you have the power to make new taxa, edit existing taxa, alter our taxonomic tree, delete taxon names, and generally maintain the state of iNat's taxonomy. The site admins do some of this in broad strokes from time to time, but we don't have the resources to keep everything current all of the time, or to vet everything we get from our data partners, so some hands-on curation is required.

Keep in mind that this document is both a how-to manual and a statement of our curatorial policies. If you cannot abide by our policies, we will start by warning you, but if you continue to reject our policies, we will remove your curator status.

Adding / Editing Taxa

Everyone on iNat can add new taxa to the system by searching external name providers using the taxon selector or by using the box at the bottom of the search page. Curators can make new taxa directly by going to or by clicking the "Create a new taxon link" in the Curation box on their dashboard.

The taxon form looks like this:

Most of the fields include some explanatory text, but here are some extra explanations:

Each Taxon record has a name, but it also has many Taxon Name records that include its scientific names (current and outdated) and vernacular names. The name field for the Taxon record should be the valid scientific name for this taxon.

You Probably Don't Want to Change the Name

Please do not change the name of a taxon if you're trying to make a taxonomic change, e.g. replacing an outdated name with a new one. The appropriate way to do this is to use Taxon Changes. Just changing the name of a taxon will not preserve the history of the change and will not notify people about the name change. The only legit reason to edit a taxon name is to fix typos.
Taxonomic rank, e.g. species, genus, family, etc.
Parent ID
ID of the parent taxon. This is how you place a taxon in our taxonomic classification. You can use the Parent Name species chooser to select the parent like you would with any other species chooser on the site, but it's the ID that gets saved, so if you want to just paste in an ID you can do that.

And of course there are caveats. For one thing, curators can't edit taxa above the order level. Changes toward the root of the tree create a ton of backend work that impacts site performance, so we stopped allowing it in July 2016. Also, these parts of the tree are pretty stable, so there's not much need to alter them. If you think these kinds of changes are needed, contact

Editing Taxa Geoprivacy Settings

iNaturalist obscures the locations of all taxa with an IUCN equivalent status of Near Threatened or 'worse'. However, if in rare situations these species are thought to be in VERY LITTLE DANGER from exploitation due to the public's knowledge of the location of these species, curators are advised to change the geoprivacy value associated with the conservation status from 'obscured' to 'open' on the taxon edit page.

Examples might be Coast Redwood which is listed as Vulnerable by IUCN because it is endangered by climate change but in very little danger of being collected or otherwise exploited by the public knowing the exact location of redwood observations. Likewise, polar bears are endangered from climate change but perhaps not from poaching.

Obviously, this is a gray area so if you feel compelled to un-obscure a threatened species be prepared to support why you are doing this. Why is the species not likely to be exploited by the public?, why is it of value to have the exact location accessible to the public?, etc.

Adding / Editing Names

Each taxon has one name (the scientific name), as well as multiple Taxon Name records. Taxon Name records are used to store all the names associated with a taxon, including current and outdated scientific names and vernacular names in multiple languages. Each name must be unique for a given taxon and lexicon.

On the left of the taxon page, you'll see a list of "All names." Any iNat user can add names using the "Add a name" link, but only curators can edit scientific names and delete names added by other people.

Default Name

Currently the default common name for a taxon is the first English name that was added to iNat. In the future curators should be able to declare a default name more explicitly, but for now it's just based on order.


In general common names should be lowercase, except for animals, which should be capitalized. Proper nouns should always be capitalized.

Good and Bad Common Names

Names, in general, should be as specific as possible, and common names are no exception. Most of us would agree that "mammal" would not be a good common name for the species Homo sapiens, so please don't add names like "snail" for some obscure gastropod with no real common name just because you think it will make it easier for novices to find. If anything, it will make it harder to find, since there are thousands and thousands of "snails." Instead, try to add names at the taxonomic level where they describe all members of that taxon and only members of that taxon. If a species has no common name in usage, please don't make one up.

For higher level taxa it can be hard to use a common name that describes all descendants. In these cases, we usually go with something like "Herons and Allies" or "heath family."

If you find names that don't meet these criteria, e.g. 10 taxa named "snail," please delete them without mercy.

Changing iNat's Taxonomy (Taxon Changes)

Taxon Changes represent changes to our taxonomic classification: swaps (1-to-1 changes), splits, and merges. There are also "taxon stages" and "taxon drops" for creating new records and deactivating existing ones, but we generally only use those when we introduced a large set of changes programmatically.

You should create a Taxon Change any time you want to change the existing taxonomy, i.e. renaming a taxon or marking it as an outdated synonym of another taxon (Taxon Swaps). You can do this by clicking the "New taxon change" button on the upper right of, or just going directly to

Check Before You Change

Before you create a new Taxon Change, check to see if someone has already done so by clicking "Taxonomic Changes" under "Extras" on the lower left of the taxon page.

Sourcing is important for Taxon Changes. While not required, we would like every change to be traced back to some publication or taxonomic authority. The ideal citation would be to the paper that introduced the change, along with a URL to that paper, but since that's often difficult / impossible to find without extensive library research, sourcing the change to a website or database is cool too. Since it's a pain to add a new Source record for every single page, it's often easier to set the Source as the website and include and specific URL to the page on that website that describes the change on the description. The goal is to ensure that anyone who wants to figure out why a particular change was made can trace it back. Keep in mind that the Encyclopedia of Life is not one of our taxonomic authorities! If you must cite them, perhaps because one of our authorities doesn't include an older synonym, please link directly to the relevant content, e.g.

The single / multiple taxon boxes are a bit confusing. Every change has input and output taxa, so if you were replacing Hyla regilla with Pseudacris regilla, Hyla regilla would be the input and Pseudacris regilla would be the output. For Taxon Splits, there is one input and multiple output taxa, so the input goes in the "Single taxon" box on the left and the outputs go in "Multiple taxa" on the right. For Taxon Merges it's the other way around: multiple inputs, one output, so the output goes on the left and the inputs on the right.

iNaturalist taxa represent taxonomic concepts, meaning taxa can represent different things even if they have the same name. So they should have distinct taxon ids and distinct taxon pages. For example, this taxonomic change split Rhipidura fuliginosa into Rhipidura albiscapa and Rhipidura fuliginosa, but the older, broader concept of Rhipidura fuliginosa has a different taxon id (8161) than the newer, narrower concept with the same name (244276). So when making a taxonomic split or merge, make sure you first make a new taxon if necessary. If the new taxon bears the same name as an existing taxon, you will need to mark the existing one as "Inactive" before the system will let you create the new one.

When you save the Taxon Change it is in an "uncommitted" state. You can review what observations will be affected by your change on the taxon change page (e.g. and update your own content at the "commit for user page" (e.g. If you're unsure about your change, you can solicit feedback through comments on the taxon change. When you're ready to execute the change, click the "commit" button. This will deactivate the input taxa, activate the output taxa, and attempt to update all observations, identifications, and list entries of the input taxa if the change is unambiguous (swaps and merges).

Note that Taxon Changes represent changes within iNaturalist's taxonomy. While this should approximately mirror the direction of changes implied by the authorities we follow, they don't have to. For example, if Authority A says Vulpes vulpes is valid, but there's a new paper that says we should call the species Supervulpes vulpes and somehow Supervulpes vulpes got added to our taxonomy, it would be ok to make a swap from Supervulpes vulpes to Vulpes vulpes, because Authority A says that's the current name.

When To Use the Merge Tool

On the lower left of the taxon pages you'll see a "Curation" box with a "Merge" link. This will take you to the Merge Tool, which is not the same as making a Taxon Merge: it deletes the taxon you're merging and moves all its associated photos, observations, etc. into the recipient record, without leaving any historical trace of who did the merging and why. We used to use this for all our taxonomic modifications until we introduced Taxon Changes, but now we only use it for situations in which duplicate taxon names get added by accident.


External Authorities

Most of our classifications come from our external name providers, but for some groups we try to adhere to different taxonomic authorities. Note that this means when we are tracking a secondary taxonomic authority like this, we explicitly do not track the taxonomy from the primary literature. We have a couple reasons for this:

  1. Taxonomy is subjective and not every scientist agrees with every paper

    While it may seem like the naming and classification of organisms is a formal process and all scientists agree on what names organisms should have, the truth is much messier. While there are standards for when and how an organism should be named, they do not apply to all taxa, and there are basically no universal standards for when two groups of organisms should be considered separate species. Biologists have never been able to agree on standards in these areas, so the result is much more akin to correct use of language than correct use of the periodic table: everyone has their own opinion, but most people tend to follow authorities (either individuals or groups) who they trust to make reasonable decisions about what names should be used. Thus, using names and classifications just because someone published a paper declaring that they should be used (even a peer-reviewed paper) is not a great idea, because it doesn't prove that the scientific community supports that paper's assertions.

  2. iNaturalist is not a place to argue about taxonomy

    Or at least we don't want it to be. Since taxonomy is subjective, people argue about it all the time, and since there is no absolute truth one can apply to settle such disputes, they can become rancorous, often to the point of absurdity. Following taxonomic authorities helps us avoid having these arguments on iNat. We can argue about which authorities to follow, but following authorities allows us to skip arguments about each and every paper.

  3. Primary sources are often hidden, while secondary sources are usually open

    iNat is largely a community of amateurs, and despite the advances made by open-access journals, the bulk of taxonomic literature is still prohibitively expensive for most amateurs to access. Avoiding the primary literature in favor of secondary taxonomic authorities, most of which are freely available on the Web, allows all our users to inspect the sources of taxonomic changes, not just the users with privileged access to the scientific literature.

  4. Following established authorities makes it easier for us to share your data with researchers

    "What taxonomy do you use?" is often one of the first questions we get from researchers interested in using our data, if we're even fortunate enough to have that discussion. More often people find our data through aggregators like GBIF, so if we're using synonymous names that researchers or GBIF doesn't know about, researchers searching GBIF won't find our data. Following authorities moderates the pace of taxonomic change in our data and increases the probability that people searching through it by name will find what they're looking for.

All that being said, there are also many situations in which we do not (or cannot) follow authorities. Sadly, many taxonomic authorities are incomplete and/or out of date, often because they are underfunded, understaffed, or suffer bizarre decisions borne out of financial or political issues that have nothing to do with taxonomy. Indeed, our own policy of following authorities has proven to be somewhat controversial, particularly for people who curate groups where there are either no authorities or the existing authorities suffer from some of these problems.

So, as a curator, what's to be done? Basically, we try match parts of our taxonomy to some taxonomic authorities, but for everything else we either accept the names and classifications we get from name providers like the Catalogue of Life and uBio, or we cite the primary literature. Here are the authorities we try to follow:

The IUCN Red List of Threatened Species
The Clements Checklist
SSAR (within the US)
The Reptile Database (Globally)
Amphibian Species of the World
Marine Invertebrates
World Register of Marine Species (WoRMS)
The World Spider Catalog

There are hardly any world authorities on any insect order, let alone all insects, so it's a tricky group. For most North American insects we try to follow BugGuide, but with deference to the following authorities:

Butterflies: A Catalogue of the Butterflies of the United States and Canada

Ground Beetles: Carabidae of the World

Ants: AntWeb

Dragonflies and Damselflies: A Checklist of North American Odonata

Bees (Andrenidae, Apidae, Colletidae, Halictidae, Megachilidae, Melittidae, Stenotritidae): ITIS World Bee Checklist

Terrestrial Isopods

Checklist of the terrestrial isopods of the new world (Crustacea, Isopoda, Oniscidea)

Vascular Plants

Plant taxonomy seems to have few centralized authorities that keep their data up-to-date. IPNI would be the ideal global source, but it seems difficult / impossible to retrieve forward synonymies, so The Plant List serves as a decent surrogate. The Kew World Checklist of Selected Plant Families is generally more up-to-date, but not comprehensive.

Regional floras tend to be more useful and up-to-date, so we try to follow a number of them, and resort to The Plant List to resolve conflicts (e.g. if Calflora thinks a dogwood is in Cornus and GoBotany thinks it's in Swida, we choose the placement favored by The Plant List). Our regional authorities are:

  • New Zealand: Ngā Tipu Aotearoa – New Zealand Plants

    Site admins for NatureWatchNZ consider this the main authority for New Zealand plants. It's pretty current and has lots of info on synonymy.

  • United States
    • California: Calflora

      Calflora uses an amalgamation of The Jepson Manual II, USDA PLANTS, and CNPS rare plant lists. We are a bit biased toward California here, but a large number of us are interested in California floristics, and we haven't run into many taxonomic conflicts with other systems, so it works for now.

    • New England: GoBotany

      GoBotany follows Flora Nova Angliae (2011) by Haines, which is recent and has relatively few conflicts with Jepson.


Sadly this is another group where there really is no global consensus, and names are changing rapidly, so for fungi we should try to follow the peer-reviewed primary literature. Index Fungorum is a decent source of names, and Species Fungorum has some information on what names should be current, but neither are up-to-date enough to satisfy most mycologists. Please be wary of IF ePublications, though, which do not require any form of peer review or supporting evidence for name publication. Same goes for Mushroom Observer, which is a fantastic site but supports a number of unpublished and provisional names.

Splitters vs. Lumpers

While our general tendency is toward lumping for the sake of simplicity, the heuristic we use is utility: if you feel some users on the site (including yourself) will benefit from having a subtribe in the system, perhaps because that's the lowest taxonomic level at which a particular insect can be identified based on a photograph, then go ahead and add it. If you're adding a subtribe just because someone somewhere decided they like taxonomic units with less than 20 species in them, don't add it, because that doesn't really help anyone on iNat.


Hybrids between species should have scientific names (the name associated with the taxon) following the pattern GENUS SPECIES1 × SPECIES2, e.g. Picoides scalaris × nuttallii for a hybrid between Picoides scalaris and Picoides nuttallii. The rank for such hybrids should be set to "hybrid." Note that the cross character is "×" and not the Roman letter "x."

Hybrids between species in different genera usually receive a generic name that is a portmanteau of the two constituent genera and a novel specific epithet, so the name of a hybrid genus should follow the pattern "× NEW_GENUS," e.g. × Chitalpa, and should receive the rank "genushybrid." The hybrid species should follow the rules above, e.g. × Chitalpa tashkentensis, and its parent would be the genus hybrid, e.g. × Chitalpa.

Keeping Track of the Taxonomic Concepts (Taxon Schemes)

Several of these External Authorities such as IUCN and NatureServe are explicit about the taxonomic concept that their names refer to, and in many cases these are different. For example, in IUCN Pseudacris regilla currently means something different (a frog whose range extends from the Pacific Northwest to Baja) than Pseudacris regilla means in Natureserve (a frog just in the Pacific Northwest). In iNat, we use Taxon Schemes to keep track of which iNaturalist taxon is the one different taxonomic authorities are referring to.


Places on iNaturalist represent physical places on Earth (no support for extraterrestrial places yet). When we started the site we pre-populated our places based on shapefiles from the US Census Bureau, the ESRI world political boundaries, and the California Protected Areas Database. We've run a few scripts since then to populate the database with some more places, but most of the rest come from user searches against the Yahoo GeoPlanet API. The remaining places were all manually created by users, and should show a "Place added" notice at the lower right of the place page showing who added it.

Anyone can add a place on iNat, but the only people who can edit it are the person who made it manually and the site curators. Here are some things to keep in mind when curating places:

  • Don't merge or delete places just because they look like duplicates. Try to figure out who added and is using a place before deciding it should go. Sometimes someone may have created a place that is similar to another but has a slightly different boundary because their project has different requirements.
  • New places don't have checklists by default, because keeping checklists up to date is actually one of the most computationally intensive things we do, so we want to minimize the number of checklists. If you only want to add a place so you can search for observations within it, please don't enable the checklist.
  • Places imported from Yahoo have no boundary defined, so even if they have a checklist, it won't be automatically updated by research grade observations. You can add a boundary by editing the place and using the map tools, or by uploading a KML file. However, if you upload KML, please don't upload really, really complicated polygons. If your places has several thousand nodes, consider simplifying the geometry before uploading.
  • Our map editing interface is fairly primitive. Using ArcGIS or QGIS will be a lot easier. Note that all our place boundary data are stored in unprojected lat/lon coordinates using the WGS84 datum.


iNat users can flag taxa that they think need curation. You can see the most recent flags in the "Curation" box on your Dashboard, and you can browse them all at Try to deal with these issues if you can, and when you do, mark the flag as resolved so it doesn't show up in the queue.

Spam and Other Inappropriate Content

We've defined inappropriate content in our FAQ (to the extent that such a definition is possible), and it will inevitably pop up from time to time. Curators can delete comments that seem inappropriate, but at present they don't have the ability to delete other kinds of records. We need a better system for dealing with this, but for now please send contact if you find inappropriate content in observation descriptions, projects, journal posts, etc.

Please keep in mind that pictures of pets, humans, obvious test observations, and drawings that depict the organism observed are appropriate, unless someone repeatedly posts such content. These kinds of observations are educational opportunities, so inform the person that iNat is primarily for sharing observations of wild organisms from nature by leaving a polite comment or private message. If 25% or more of a user's observations are of pets, humans, abiotic phenomena, or other off-topic subjects, or if they persist in this kind of behavior despite being warned, that constitutes abuse and you should contact the site admins at, who will give the user 24 hours to remove the off- topic content, after which they will simply remove it for them. All that being said, a few off-topic observations here and there are ok.

An additional note regarding drawings: drawings are ok because, like photos, they can show visual evidence of the individual organism observed. If you don't think the drawing was of the observed organism (e.g. it's just a drawing of the species, not of an individual), talk to the observer and ask them to clarify what their drawing depicts. If they admit the drawing is not of an individual organism they observed, please contact and the admins will ask the user to remove the photo, and remove it for them if they don't comply. If you cannot identify the organism from the drawing, treat it like a blurry photo and vote that the community cannot improve the ID.

Editing This Wiki

Curators can edit wiki pages like this one and the other help pages by clicking the "Edit" link at the bottom right of the page. You can create new pages by visiting the URL you want (e.g. or by clicking to it from an existing page using the internal link syntax (e.g. somepage) and clicking the link.

Wiki pages support full HTML as well as Markdown formatting. The Formatting box on the edit form will show you what's available.

Revised on January 18, 2017 04:01 PM by loarie loarie
Member of the iNaturalist Network   |   Powered by iNaturalist open source software