Contact sales

The Reader API is free of charge and does not require an API key. Simply prepend 'https://r.jina.ai/' to your URL.

The Reader API uses a proxy to fetch any URL, rendering its content in a browser to extract high-quality main content.

Yes, the Reader API is open source and available on the Jina AI GitHub repository.

The Reader API generally processes URLs and returns content within 2 seconds, although complex or dynamic pages might require more time.

Scraping can be complicated and unreliable, particularly with complex or dynamic pages. The Reader API provides a streamlined, reliable output of clean, LLM-ready text.

The Reader API returns content in the original language of the URL. It does not provide translation services.

If you experience blocking issues, please contact our support team for assistance and resolution.

Yes, the Reader API can natively extract content from PDF files.

Currently, the Reader API does not process media content, but future enhancements will include image captioning and video summarization.

No, the Reader API can only process content from publicly accessible URLs.

If you request the same URL within 5 minutes, the Reader API will return the cached content.

Unfortunately not.

Yes, you can either use the native PDF support from the Reader (https://r.jina.ai/https://arxiv.org/pdf/2310.19923v4) or use the HTML version from the arXiv (https://r.jina.ai/https://arxiv.org/html/2310.19923v4)

Reader captions all images at the specified URL and adds `Image [idx]: [caption]` as an alt tag (if they initially lack one). This enables downstream LLMs to interact with the images in reasoning, summarizing etc.

The Reader API is designed to be highly scalable. It is auto-scaled based on the real-time traffic and the maximum concurrency requests is now around 4000. We are maintaining it actively as one of the core products of Jina AI. So feel free to use it in production.

Please find the latest rate limit information in the table below. Note that we are actively working on improving the rate limit and performance of the Reader API, the table will be updated accordingly.

The pricing for the Reranker API is aligned with our Embedding API pricing structure. It begins with 1 million free tokens for each new API key. Beyond the free tokens, different packages are available for purchase. For more details, please visit our pricing section.

The primary difference lies in their architecture. For performance, we recommend jina-reranker-v1, which has been extensively tested and benchmarked against competitors. Jina-reranker-v1 utilizes a cross-encoder architecture, while Jina-colbert-v1 is based on the ColBERTv2 architecture but extends the context length of both the query and document to 8192, achieving even better performance than the original ColBERTv2 model.

Yes, jina-colbert-v1 is open source and can be accessed via Huggingface. However, jina-reranker-v1 is not open source.

Currently, it supports English only. However, some users have reported that it also works well with Chinese. This may be partly because jina-reranker-v1-base-en shares some weights with our jina-embeddings-v2-base-zh embedding model.

The maximum query token length is 512. There is no token limit for documents.

You can rerank up to 2048 documents per query.

There is no concept of batch size unlike our Embedding API. You can send only one query-document tuple per request, but the tuple can include up to 2048 candidate documents.

Latency varies from 100 milliseconds to 7 seconds, depending largely on the length of the documents and the query. For instance, reranking 100 documents of 256 tokens each with a 64-token query takes about 150 milliseconds. Increasing the document length to 4096 tokens raises the time to 3.5 seconds. If the query length is increased to 512 tokens, the time further increases to 7 seconds.

Yes, Jina Reranker can be deployed on AWS. If you require on-premises deployment in an enterprise setting, you can easily do so via our AWS Marketplace offering.

If you are interested in a fine-tuned reranker tailored to specific domain data, please contact our sales team. Our team will respond to your inquiry promptly.

For detailed information on our training processes, data sources, and evaluations, please refer to our technical report available on arXiv.

Jina CLIP jina-clip-v1 is the latest multimodal embedding model that supports text-text, text-image, image-image, and image-text retrieval tasks. Unlike OpenAI CLIP model that falls short on text-text search, Jina CLIP is trained to be your text retriever. You can read more about it from our tech report.

Our models support English, German, Spanish, Chinese, various programming languages and images. For more details, please refer to our publication on bilingual models.

Our models allow for an input length of up to 8192 tokens, which is significantly higher than most other models. A token can range from a single character, like 'a', to an entire word, such as 'apple'. The total number of characters that can be input depends on the length and complexity of the words used. This extended input capability enables our jina-embeddings-v2 models to perform more comprehensive text analysis and achieve higher accuracy in context understanding, especially for extensive textual data.

A single API call can process up to 2048 sentences or texts, facilitating extensive text analysis in one request.

You can use either url or bytes in the input field of the API request. For url, provide the URL of the image you want to process. For bytes, encode the image in base64 format and include it in the request. The model will return the embeddings of the image in the response.

According to the MTEB Leaderboard, our Base model competes closely with OpenAI’s text-embedding-ada-002, exhibiting comparable performance on average. Furthermore, our Base model excels in several tasks, including classification, pair-classification, re-ranking, and summarization, outperforming OpenAI’s model.

The transition is streamlined, as our API endpoint, https://api.jina.ai/v1/embeddings, matches the input and output JSON schemas of OpenAI’s text-embeddings-ada-002 model. This compatibility ensures users can easily replace the OpenAI model with ours when using OpenAI’s endpoint.

The tokens are calculated based on the text length and image size. For text in the request, tokens are counted in the standard way. For image in the request, the following steps are conducted: 1. Tile Size: Each image is divided into tiles of size 224x224 pixels. 2. Coverage: The number of tiles required to completely cover the input image is calculated. Even if the image dimensions are not perfectly divisible by 224, we will count partial tiles as full tiles. 3. Total Tiles: The total number of tiles covering the image determines the cost. For instance, if an image is 500x500 pixels, it would be covered by 3x3 tiles, resulting in 9 tiles. 4. Cost Calculation: Each tile contributes to the final cost of processing the image. The cost per tile is 1000 tokens. Example: For an image with dimensions 500x500 pixels: • The image is divided into 224x224 pixel tiles. • The total number of tiles required is 3 (horizontal) x 3 (vertical) = 9 tiles. • The cost will be 9*1000 = 9000 tokens

Yes, jina-clip-v1 can embed both images and texts. Embedding models on more modalities will be announced soon!

For inquiries about fine-tuning our models with specific data, please contact us to discuss your requirements. We are open to exploring how our models can be adapted to meet your needs.

Yes, our services are available on the AWS marketplace, and we are in the process of expanding to Azure and GCP marketplaces. If you have particular requirements, please contact us at sales AT jina.ai.

Zero-shot requires semantic labels during classification and none during training, while few-shot requires labels during training but not classification. This means zero-shot is better for flexible, immediate classification needs, while few-shot is better for fixed, domain-specific categories that can evolve over time.

num_iters controls training intensity - higher values reinforce important examples while lower values minimize impact of less reliable data. It can be used to implement time-aware learning by giving recent examples higher iteration counts, making it valuable for evolving data patterns.

Public classifiers can be used by anyone with the classifier_id, consuming their own token quota. Users can't access training data or configuration, and can't see others' classification requests, enabling safe classifier sharing.

Few-shot requires 200-400 training examples to outperform zero-shot classification. While it ultimately achieves higher accuracy, it needs this warm-up period to become effective. Zero-shot provides consistent performance immediately without training data.

Yes - the API supports multilingual queries using jina-embeddings-v3 and multimodal (text/image) classification using jina-clip-v1, with support for URL or base64 encoded images in the same request.

Zero-shot supports 256 classes with no classifier limit, while few-shot is limited to 16 classes and 16 classifiers. Both support 1,024 inputs per request and 8,192 tokens per input.

Few-shot mode allows continuous updating through the /train endpoint for adapting to changing data patterns. You can incrementally add new examples or classes when data distribution changes, without rebuilding the entire classifier.

The API uses one-pass online learning - training examples update classifier weights but aren't stored afterward. This means you can't retrieve historical training data, but it ensures privacy and resource efficiency.

Start with zero-shot for immediate results and when you need flexible classification with semantic labels. Switch to few-shot when you have 200-400 examples, need higher accuracy, or need to handle domain-specific/time-sensitive data.

Yes, you can choose between jina-embeddings-v3 for text classification (especially good for multilingual) and jina-clip-v1 for multimodal classification. New models like jina-clip-v2 will be automatically available through the API when released.

The Segmenter API is free to use. By providing your API key, you can access a higher rate limit, and your key won't be charged.

Without an API key, you can access the Segmenter API at a rate limit of 20 RPM.

With an API key, you can access the Segmenter API at a rate limit of 200 RPM. For premium paid users, the rate limit is 1000 RPM.

No, your API key is only used to access a higher rate limit.

Yes, the Segmenter API is multilingual and supports over 100 languages.

GET requests are solely used to count the number of tokens in a text, allows you easily integrate it as a counter in your application. POST requests supports more parameters and features, such as returning the first/last N tokens.

You can send up to 64k characters per request.

The chunking feature segments long documents into smaller chunks based on common structural cues, ensuring accurate segmentation of text into meaningful chunks. Essentially it is a (big!) regex pattern that segments text based on certain syntactical features that often align with semantic boundaries, such as sentence endings, paragraph breaks, punctuation, and certain conjunctions. It is not semantic chunking. This (big) regex is as powerful as it can be within the limitations of regular expressions. It balances complexity and performance. While true semantic understanding isn't possible with regex, it well-approximates context by common structural cues.

If the input contains special tokens, our Segmenter API will put them in the field 'special_tokens'. This allows you to easily identify them and handle them accordingly for your downstream tasks, e.g. removing them before feeding the text into an LLM to prevent injection attacks.

Besides western languages, chunking also works well with Chinese, Japanese, and Korean.

The feature is currently in beta and costs 1M tokens per fine-tuned model. You can use your existing API key from the Embedding/Reranker API if it has sufficient tokens, or you can create a new API key, which includes 1M free tokens.

You don't need to provide any training data. Simply describe your target domain (the domain for which you want the fine-tuned embeddings to be optimized) in natural language, or use a URL as a reference, and our system will generate synthetic data to train the model.

About 30 minutes.

The fine-tuned models and synthetic data are stored publicly in the Hugging Face model hub.

The system uses the Reader API to fetch the content from the URL. It then analyzes the content to summarize the tone and domain, which it uses as guidelines for generating synthetic data. Therefore, the URL should be publicly accessible and representative of the target domain.

Yes, you can fine-tune a model for a non-English language. The system automatically detects the language of your domain instructions and generates synthetic data accordingly. We also recommend choosing the appropriate base model for the target language. For example, if targeting a German domain, you should select the 'jina-embeddings-v2-base-de' as the base model.

No, our fine-tuning API only supports Jina v2 models.

At the end of the fine-tuning process, the system evaluates the model using a held-out test set and reports performance metrics. You will receive an email detailing the before/after performance on this test set. You are also encouraged to evaluate the model on your own test set to ensure its quality.

The system generates synthetic data by integrating the target domain instruction you provide with LLM agents' reasoning. It produces hard negative triplets, which are essential for training high-quality embedding models. For more details, please refer to our upcoming research paper on Arxiv.

Currently, no. Note that this feature is still in beta. Storing the fine-tuned models and synthetic data publicly in the Hugging Face model hub helps us and the community evaluate the quality of the training. In the future, we plan to offer a private storage option.

Since all fine-tuned models are uploaded to Hugging Face, you can access them via SentenceTransformers by simply specifying the model name.

Please check your spam folder. If you still can't find it, please contact our support team using the email address you provided.

Yes, the same API key is valid for all search foundation products from Jina AI. This includes the embedding, reranking, reader and fine-tuning APIs, with tokens shared between the all services.

Yes, token usage can be monitored in the 'Buy tokens' tab by entering your API key, allowing you to view the usage history and remaining tokens.

If you have misplaced a topped-up key and wish to retrieve it, please contact support AT jina.ai with your registered email for assistance.

No, our API keys do not have an expiration date. However, if you suspect your key has been compromised and wish to retire it or transfer its tokens to a new key, please contact our support team for assistance.

This is because our serverless architecture offloads certain models during periods of low usage. The initial request activates or 'warms up' the model, which may take a few seconds. After this initial activation, subsequent requests process much more quickly.

We adhere to a strict privacy policy and do not use user input data for training our models.

Our pricing model is based on the total number of tokens processed, allowing users the flexibility to allocate these tokens across any number of sentences, offering a cost-effective solution for diverse text analysis requirements.

We offer a welcoming free trial to new users, which includes one million tokens for use with any of our models, facilitated by an auto-generated API key. Once the free token limit is reached, users can easily purchase additional tokens for their API keys via the 'Buy tokens' tab.

No, tokens are not deducted for failed requests.

Payments are processed through Stripe, supporting a variety of payment methods including credit cards, Google Pay, and PayPal for your convenience.

Yes, an invoice will be issued to the email address associated with your Stripe account upon the purchase of tokens.