Best NER APIs & Models in 2026: Benchmarks & Pricing

What is Named Entity Recognition (NER)?

Named entity recognition identifies spans of text that refer to real-world entities and assigns each span to a category. Standard NER models usually extract:

• Person: names of individuals
• Organization: companies, institutions, and public bodies
• Location: countries, cities, addresses, and geographic areas
• Date: calendar dates and time periods
• Money: monetary amounts and currencies
• Percentage: ratios expressed as percentages

For example: “Microsoft invested €15 million in Paris in March 2026.”

• Microsoft: ORGANIZATION
• €15 million: MONEY
• Paris: LOCATION
• March 2026: DATE

Standard NER works best when your target fields match common categories and your documents use familiar language. It is often enough for news analysis, document indexing, support-ticket routing, compliance screening, and basic information extraction.

Custom or domain-specific NER handles labels that a general model does not know. A legal team might extract contracting party, termination date, and governing law. A healthcare product might need medication, dosage, and symptom. A recruitment platform could identify job title, technical skill, and degree.

Custom NER can mean training a model on annotated examples, adding dictionaries and rules, or defining labels at inference time with a zero-shot model or LLM. The right method depends on label stability, available training data, privacy constraints, expected volume, and tolerance for inconsistent outputs.

The real choice is between a managed NER API, a self-hosted open-source model, and LLM-based extraction.

How to Evaluate a NER API or Model in 2026

F1, precision, and recall

F1 is useful for comparing models because it balances precision and recall, but the average can hide the failure mode that matters to your product. Precision tells you how many extracted entities are correct. Recall tells you how many real entities the model finds.

For PII detection, compliance checks, and document redaction, recall often matters more. Missing a passport number or customer name can create more risk than flagging a harmless phrase for review. For automatic database updates, higher precision may matter more because false entities can pollute downstream records.

Ask the vendor: “Can you provide precision, recall, and F1 by entity type on data similar to ours, rather than one aggregate score?”

Entity type coverage

Check the actual taxonomy, not the phrase “named entity recognition.” One API may identify people, organizations, locations, dates, money, and percentages. Another may only cover people, organizations, locations, and miscellaneous entities.

A fixed taxonomy creates a hard ceiling. It cannot extract fields such as contract clause, product SKU, adverse event, job skill, or insurance policy number unless the provider offers custom NER.

Ask the vendor: “Which entity labels are supported natively, and what happens when we need a label outside that list?”

Language support

A long language list does not mean equal quality across languages. Providers often test English more heavily, while lower-resource languages receive less training data and weaker evaluation. Quality can also fall on mixed-language documents, regional spelling, transliterated names, and local address formats.

Test each language using your own documents and measure results separately. Do not average English and non-English performance into one score.

Ask the vendor: “What are your precision and recall results for each language we plan to process, on which dataset, and for which entity types?”

Latency and throughput

Real-time use cases need predictable response times, not only a low average. Look at p95 and p99 latency, request limits, document-size limits, concurrency, and cold starts. For large archives, batch processing speed and job-retry behavior matter more than single-request latency.

Also check whether the provider charges or throttles per document, character, token, or request.

Ask the vendor: “What throughput and p95 latency can you commit to at our expected document size and concurrency?”

Custom entity training

Custom NER may require annotated documents, a training pipeline, model hosting, and repeated retraining as your taxonomy changes. Some providers handle this inside their platform. Others expect you to prepare training files and manage evaluation yourself.

The main cost is often not compute, but annotation, review, and maintaining consistent labeling rules.

Ask the vendor: “How many labeled examples do you require per entity type, and what do annotation, training, deployment, and retraining cost?”

Data residency and GDPR

Confirm where the API receives, processes, logs, and stores text. A European endpoint does not always mean every model request stays in Europe. Prompts may pass through another region for inference, monitoring, abuse detection, or support.

Check retention defaults, training use, subprocessors, deletion periods, and whether logging can be disabled.

Ask the vendor: “Can you contractually confirm that our text stays within the selected region, including inference, logs, backups, and subprocessors?”

The 9 Best NER APIs in 2026 

Amazon Comprehend

Amazon Comprehend is a practical choice for conventional NER inside AWS-based applications. Its prebuilt recognizer covers standard entities, while custom entity recognition lets you train labels tied to your domain, such as product references, policy numbers, or internal document categories.

Its standard NER supports 12 languages, slightly more than Google Cloud Natural Language but far fewer than Microsoft Azure AI Language. That difference matters for multilingual products, even though all three services are commonly described as multilingual.

Amazon costs $1.00 per 1 million characters on Eden AI. The price stays flat rather than dropping at higher volumes, which makes it easy to forecast but less competitive than tiered services once you process billions of characters.

Pros

• Clear character-based pricing
• Standard and custom entity recognition
• Supports real-time and batch processing

Cons

• Limited to 12 languages for standard NER
• Custom models require labeled data and training

Microsoft Azure AI Language

Microsoft Azure AI Language stands out for language coverage. Its generally available NER supports 79 languages, with about 94 languages in preview. That is more than six times the coverage of Amazon Comprehend, its nearest managed rival in this comparison.

Azure also offers custom NER for labels outside its standard taxonomy. This suits products that need entities such as contract type, technical skill, medical device, or internal department. Custom NER is a training workflow, not a prompt-based feature, so you need labeled examples, evaluation data, and a deployed model.

Microsoft costs $1.00 per 1 million characters on Eden AI. Like Amazon and Tenstorrent, that is a flat entry price without a volume commitment or tier conversion.

Pros

• 79 generally available NER languages
• Custom NER for domain-specific labels
• Predictable character-based billing

Cons

• Quality can still vary across its supported languages
• Custom NER requires annotation and model training
• Flat pricing does not become cheaper at high volume

OpenAI GPT-4o

GPT-4o handles NER as instruction-based structured extraction rather than as a fixed entity-recognition service. You can define labels such as governing_law, candidate_skill, or adverse_event inside the request and return the results as structured JSON.

That flexibility is useful when the schema changes frequently or an entity depends on context. It also avoids training a separate custom model for every new label. However, OpenAI has not published an NER-specific benchmark across languages, so broad multilingual capability should not be treated as evidence of equal entity accuracy.

GPT-4o costs $10.00 per 1 million tokens on Eden AI. At roughly 3.8 English characters per token, that is about $2.63 per 1 million characters. Chinese and Japanese can approach one token per character, raising the normalized cost toward $10.00 per 1 million characters.

Pros

• Supports arbitrary entity schemas through instructions
• Handles contextual extraction rules
• Can return schema-constrained JSON

Cons

• No published NER-specific multilingual benchmark
• Costs vary sharply with language and tokenizer behavior

Tenstorrent

Tenstorrent is available through Eden AI at $1.00 per 1 million characters, matching the verified entry price for Amazon and Microsoft. The main issue is not price, but product transparency. Tenstorrent is primarily known for AI hardware and inference infrastructure. 

Pros

• Flat character-based pricing
• Available through the same Eden AI integration
• No self-hosted deployment required

Google Cloud Natural Language

Google Cloud Natural Language supports entity analysis in 11 languages: English, French, German, Italian, Japanese, Korean, Portuguese, Russian, Spanish, Simplified Chinese, and Traditional Chinese. It returns entity types, mentions, salience, and knowledge-base links.

Google includes 5 million characters per month free. Paid pricing starts around $1.00 per million characters, falls to $0.50 above 1 billion, and reaches $0.25 above 5 billion characters.

Pros

• Useful entity linking and salience signals
• Generous monthly free allowance
• Strong pricing at very high volume

Cons

• Only 11 NER languages
• No custom NER in the standard entity-analysis API

IBM Watson Natural Language Understanding

IBM Watson NLU combines entities with features such as sentiment, relations, concepts, and categories. Its free tier includes 30,000 items per month, with paid entry pricing of $0.003 per item.

Using a 10,000-character item, one enrichment feature works out to about $0.30 per million characters at the entry tier, then roughly $0.10 to $0.02 at volume. Each added enrichment feature consumes another item, so entities plus sentiment would cost about twice as much.

IBM appears to support six built-in entity languages, with more available through custom models.

Pros

• Low normalized price for single-feature workloads
• Combines NER with other text-analysis features
• Supports custom models

Cons

• Costs multiply when you request several enrichments
• Item-based billing is harder to compare
• Official language coverage needs manual confirmation

Lettria

Lettria has moved beyond a conventional NER API. It now positions itself around document intelligence, knowledge graphs, and GraphRAG, with entity and relationship extraction as part of a wider platform.

It can suit projects that need a domain ontology and a structured graph built from documents. It is less comparable to a simple endpoint that returns people, organizations, and locations. Lettria does not publish self-service pricing, so the correct entry is contact for pricing.

Pros

• Custom ontologies and relationship extraction
• Built for knowledge-graph workflows

Cons

• No public pricing
• Not a direct substitute for a lightweight NER API
• Broader implementation scope than basic entity extraction

NLP Cloud

NLP Cloud offers hosted NER through several model families, so language coverage and behavior depend on the model you select. It also provides CPU, GPU, dedicated, and private deployment options.

Usage-based pricing is listed at about $0.003 per CPU request and $0.005 per GPU request, with $15 in free credit. Prepaid plans range from $29 to $229 for CPU and from $99 to $2,499 for GPU.

Pros

• Choice of hosted open-source and generative models
• Private deployment options
• Low entry cost for testing

Cons

• Request pricing cannot be normalized without document size
• Quality and language support vary by model
• Model selection adds evaluation work

TextRazor

TextRazor combines NER with entity linking, disambiguation, relations, topic extraction, and custom dictionaries. It supports NER in 19 languages, not 142. The larger number refers to language detection, not entity extraction.

The free tier includes 500 requests per day. Paid plans are listed at $200, $600, and $1,200 per month. Since billing is request-based, the effective cost depends on how much text you send in each request.

Pros

• 19 NER languages
• Detailed entity linking and knowledge-base data
• Free tier suitable for prototypes

Cons

• Request-based pricing is difficult to compare
• Custom dictionaries are not equivalent to a trained contextual NER model
• Language detection coverage can be mistaken for NER coverage

Best Open-Source NER Models and Libraries in 2026

spaCy

spaCy remains the production default when you need fast, predictable NER without building an entire machine-learning stack. Its small and medium pipelines run efficiently on CPUs, making them suitable for synchronous APIs, document queues, and applications with limited infrastructure. Transformer pipelines provide better accuracy but usually need a GPU for acceptable throughput.

Pretrained pipelines require no labeled training data, but their entity taxonomy is fixed. For example, the English pipelines commonly identify people, organizations, locations, dates, money, percentages, products, events, and related OntoNotes categories. They cannot immediately recognize a domain label such as contract_clause or drug_dosage. You need labeled examples, rules, or a custom pipeline for that.

The spaCy library uses the MIT license, although individual model packages may use different licenses. spaCy provides trained pipelines for about 25 languages, but not every pipeline includes NER.

Pros

• Fast CPU inference
• Mature training, packaging, and deployment tools
• Statistical NER can be combined with dictionaries and rules

Cons

• Pretrained models use fixed entity taxonomies
• Language and entity coverage varies by pipeline
• Transformer pipelines are heavier than standard spaCy models

GLiNER

GLiNER is the strongest open-source choice when your entity labels change frequently. You provide a list such as ["medical device", "adverse event", "manufacturer"] at inference time, and the model extracts matching spans without task-specific retraining. This gives it some of the flexibility of LLM prompting while retaining the speed and local deployment options of an encoder model.

Reported PII-focused evaluations place the base model at roughly 81% F1 and the larger variant near 83% F1. These are PII benchmark results, not general NER scores. They do not establish how the same models perform on legal clauses, products, scientific entities, or another custom taxonomy.

GLiNER uses the Apache 2.0 license. It can run on CPU, including through ONNX and quantized deployments, but a GPU is preferable for larger models, long documents, or high request volumes. Zero-shot use requires no labeled data. Fine-tuning with labeled examples remains available when the zero-shot results are insufficient.

Pros

• Arbitrary labels supplied at inference time
• No labeled data required for zero-shot extraction
• Smaller and faster than a generative LLM

Cons

• Label wording can materially change results
• PII benchmark scores do not transfer automatically to other domains
• Fixed-taxonomy fine-tunes can still win on stable, well-labeled tasks

Flair

Flair is a good fit when accuracy matters more than raw throughput. Its sequence taggers combine contextual embeddings, document-level context, and transformer models. The library also makes it possible to mix different embeddings or train a tagger for your own entity taxonomy.

The ner-english-large model reports 94.36 F1 on corrected CoNLL-03, but that benchmark covers only four labels: person, location, organization, and miscellaneous. It says little about dates, money, percentages, PII, or industry-specific entities. The model is based on document-level XLM-R embeddings, so it is heavier than a CPU-oriented spaCy pipeline.

Flair uses the MIT license. Pretrained models require no labeled data. Training a new taxonomy does. Small taggers can run on CPU, but the larger contextual and transformer models are better suited to a GPU, especially for batch workloads. Flair itself is built on PyTorch.

Pros

• Strong benchmark accuracy for supported taxonomies
• Large catalogue of language and domain models
• Flexible custom sequence-tagger training

Cons

• Large models have slower inference
• GPU use is advisable for the strongest models
• Benchmark results often cover narrow entity sets

Stanza

Stanza is the strongest general choice when language coverage matters more than having the fastest English pipeline. It comes from the Stanford NLP Group and provides tokenization, lemmatization, part-of-speech tagging, dependency parsing, and NER inside one neural pipeline.

NER models are listed for more than 30 languages, while the wider Stanza toolkit covers over 60. That makes it useful when you need similar processing stages across many languages rather than separate libraries for each market. Do not assume equal NER quality across them. Training corpora, annotation schemes, entity labels, and available data differ by language.

Stanza uses the Apache 2.0 license. Its pretrained NER packages need no labeled data. Training a new language model or entity taxonomy requires annotated examples. CPU inference is practical for moderate workloads, but the neural pipeline is heavier than spaCy’s smaller statistical packages. A GPU is preferable for training or processing large collections.

Pros

• Wide multilingual NER coverage
• Full linguistic pipeline from one library
• Research-backed models from Stanford

Cons

• Slower than lightweight CPU-first pipelines
• Entity taxonomies differ across languages
• Custom training requires familiarity with Stanza’s data format and pipeline

ModernBERT and transformer fine-tunes

A fine-tuned encoder model is usually the best route when you have a stable taxonomy, labeled data, and need the highest possible accuracy on your own documents. ModernBERT is a current starting point for English workloads. It supports inputs up to 8,192 tokens and comes in 149-million and 395-million-parameter variants. The base model is not an NER system out of the box. You must add a token-classification head and fine-tune it on labeled spans.

ModernBERT’s code and weights use the Apache 2.0 license. Training normally requires a GPU. The base variant can run on a capable CPU after training, but GPU inference is preferable for long documents or high throughput. The larger model has higher memory and latency requirements.

Other transformer encoders, including BERT, RoBERTa, DeBERTa, and language-specific variants, follow the same pattern. Their licenses vary by checkpoint.

Pros

• Strongest path to high in-domain accuracy
• Full control over taxonomy and deployment
• Stable, reproducible output after training

Cons

• Requires labeled token-level training data
• Training and error analysis demand ML expertise
• A new label usually means annotation and retraining

Domain-specific models for biomedical and PII extraction

General NER models often fail after a domain shift. Biomedical text contains gene symbols, proteins, chemicals, diseases, abbreviations, and nested spans that news-trained models were never designed to classify. PII detection adds phone numbers, account identifiers, IP addresses, passport numbers, and local address patterns.

For biomedical extraction, scispaCy provides scientific and biomedical pipelines plus entity linking to resources such as UMLS. It uses the Apache 2.0 license and can run on CPU, although larger pipelines and linking indexes need more memory. Its pretrained packages require no labeled data. Custom categories still require training or rules.

For PII, Presidio combines NLP models, pattern matching, checksums, and custom recognizers. It uses the MIT license and runs comfortably on CPU for many workloads. Prebuilt recognizers need no training data, while organization-specific identifiers require rules or labeled examples.

Pros

• Taxonomies and preprocessing match the target domain
• Better starting point than general news NER
• Often combines models with rules and entity linking

Cons

• Biomedical and PII tools are not interchangeable
• Performance can drop on a new document type or jurisdiction
• Domain-specific errors can carry higher legal or clinical consequences

Using LLMs for Named Entity Recognition

LLM extraction is a third approach alongside managed NER APIs and self-hosted encoder models. Instead of selecting a fixed NER taxonomy or training a token classifier, you describe the entities you need and require the model to return structured data.

A request can look like this:

Extract all entities from the document.

Entity types:
- contracting_party
- effective_date
- governing_law
- termination_notice_period

Return JSON matching this schema:

{
  "entities": [
    {
      "text": "string",
      "type": "string",
      "start": 0,
      "end": 0,
      "evidence": "string"
    }
  ]
}

‍

APIs with structured output support can constrain the response to a JSON schema, which removes much of the parsing work. Schema enforcement guarantees the response shape, however, not that every span or classification is correct.

The main advantage is arbitrary entity coverage with no labeled training set. You can add renewal_condition today and liability_cap tomorrow without annotating hundreds of examples or retraining a model. An LLM can also apply contextual rules. It may distinguish a contract’s governing law from a country mentioned only in a customer address, for example.

That flexibility carries measurable costs. Based on the normalization in section 4, GPT-4o is roughly 2.5 times more expensive per English character than the dedicated APIs priced at $1.00 per million characters. Token costs also vary by language. LLM inference generally has higher latency because the model generates the output token by token.

The output is less reproducible as well. Two calls can return different boundaries, omit different entities, or interpret an ambiguous label differently. Low temperature, pinned model versions, strict schemas, and regression tests reduce variation, but they do not turn a generative model into a deterministic tagger.

LLM extraction tends to win when:

• Volume is low to moderate
• Entity types are unusual or change frequently
• You need a working prototype before building a labeled dataset
• Classification depends on meaning spread across a sentence or document

It tends to lose when:

• You process large, steady text volumes
• The taxonomy is fixed and well understood
• The application has a strict latency budget
• Identical inputs must produce identical spans every time

GPT-4o is available on Eden AI at $10.00 per 1 million tokens, before the 5.5% platform fee. It supports structured outputs, but you still need an evaluation set that measures span accuracy, missed entities, and schema-specific mistakes.

What NER Actually Costs: Characters vs Tokens

NER prices often look comparable until you check the billing unit. Amazon Comprehend, Microsoft Azure AI Language, and Tenstorrent charge by character. OpenAI GPT-4o charges by token. A price per million tokens is not a price per million characters, so comparing the headline figures directly gives the wrong answer.

The character-billed providers cost: $1.00 per 1 million characters

GPT-4o costs: $10.00 per 1 million tokens

For English text, one token represents roughly four characters on average. That means: 

1 million tokens × 4 characters per token = about 4 million characters

You can then normalize GPT-4o’s price: $10.00 ÷ 4 million characters = $2.50 per 1 million characters

On that assumption, GPT-4o costs roughly 2.5 times as much per English character as Amazon, Microsoft, or Tenstorrent.

This conversion becomes less reliable outside English. Tokenizers do not divide every language into text units at the same rate. Chinese, Japanese, and Arabic usually consume more tokens per character than English, so the effective cost per million characters rises.

The formula is: Normalized cost per 1M characters = token price ÷ characters per token

A managed NER API billed at $1.00 per 1M characters has a fixed cost regardless of language. A token-billed model does not. GPT-4o at $10.00 per 1M input tokens works out to about $2.27 per 1M characters of English, because English averages roughly 4.4 characters per token under GPT-4o's tokenizer.

That ratio collapses on non-Latin scripts. Chinese averages about 1.3 characters per token, so the same $10.00 covers only ~1.3M characters instead of ~4.4M. The normalized cost rises to about $7.73 per 1M characters, roughly 7.7x the character-billed alternative. Japanese lands near $7.38, Korean near $6.63, Arabic near $3.48.

Two things follow. Token-billed extraction is most expensive on precisely the multilingual workloads people assume an LLM handles best. And the ratio worsens with entity density: clean prose tokenizes efficiently, while text full of names, dates, account numbers and identifiers tokenizes badly, which describes most real NER input.

Measure this on your own corpus before committing. The ratio is a property of your documents, not just the language.

Get Started with NER on Eden AI

Creating an Eden AI account gives you an API key, access to the unified API, and a dashboard for monitoring usage, costs, latency, and errors. The self-service plan is pay as you go, with no subscription or volume commitment.

You can test Amazon Comprehend, Microsoft Azure AI Language, Tenstorrent, and OpenAI GPT-4o using the same NER endpoint. Send each provider your own representative text, then compare entity coverage, missed spans, false positives, latency, and cost before selecting a default. Switching providers only requires changing the model string in the request.

import os
import requests

url = "https://api.edenai.run/v3/universal-ai"
headers = {"Authorization": f"Bearer {os.environ['EDENAI_API_KEY']}"}

models = [
    "text/named_entity_recognition/amazon",
    "text/named_entity_recognition/microsoft",
    "text/named_entity_recognition/openai/gpt-4o",
    "text/named_entity_recognition/tenstorrent",
]

for model in models:
    response = requests.post(
        url,
        headers=headers,
        json={
            "model": model,
            "input": {
                "text": "Microsoft invested $5 million in Paris in March 2026.",
                "language": "en",
            },
        },
        timeout=60,
    )
    response.raise_for_status()

    print(f"\n=== {model} ===")
    for entity in response.json()["output"]["items"]:
        print(entity["entity"], ":", entity["category"])

‍

See the NER API documentation for the endpoint, model strings, input fields, and response format. 

FAQs - Best NER APIs & Models in 2026