Best Translation API
for Next.js

Rule one for translation in Next.js: the API key never leaves the server. Anything under app/ that is marked "use client" ships to the browser, and so does every NEXT_PUBLIC_ variable. A Route Handler gives you a small, typed proxy that your client components can call safely.

Langbly speaks the Google Translate v2 request and response format, so a single fetch is all you need:

// app/api/translate/route.ts
import { NextResponse } from "next/server";

type TranslateBody = {
  q: string;
  target: string;
  source?: string;
};

export async function POST(request: Request) {
  const { q, target, source } = (await request.json()) as TranslateBody;

  if (!q || !target) {
    return NextResponse.json(
      { error: "Both q and target are required" },
      { status: 400 }
    );
  }

  const response = await fetch(
    "https://api.langbly.com/language/translate/v2",
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Authorization: "Bearer " + process.env.LANGBLY_API_KEY,
      },
      body: JSON.stringify({ q, target, source, format: "text" }),
    }
  );

  if (!response.ok) {
    return NextResponse.json(
      { error: "Translation failed" },
      { status: response.status }
    );
  }

  const json = await response.json();
  const [translation] = json.data.translations;

  return NextResponse.json({
    text: translation.translatedText,
    detectedSource: translation.detectedSourceLanguage,
  });
}

The response body comes back as {"data":{"translations":[{"translatedText":"Hallo wereld","detectedSourceLanguage":"en"}]}}, the exact shape the Google v2 API returns. If you already have a Next.js app wired to Google Translate, you swap the base URL and the auth header and the rest of your code keeps working.

Prefer a typed client over raw fetch? The official SDK is on npm as langbly, written in TypeScript, with auto-retry and typed error classes.

// lib/langbly.ts
import { Langbly } from "langbly";

export const langbly = new Langbly({
  apiKey: process.env.LANGBLY_API_KEY!,
});

Google's client is the awkward one here. It authenticates with a service account JSON file, which means either a file on disk your deploy target may not have, or a base64 environment variable you decode at boot. DeepL and Langbly both take a plain key string, which is one line in your hosting dashboard.

Most Next.js projects have two kinds of text, and they want different treatment.

Static UI copy (nav labels, buttons, marketing sections) does not change per request. Translate it once during the build, write JSON locale files, and let next-intl or your own dictionary read them. Zero API calls at runtime, zero latency, and the cost is a one-off.

// scripts/build-locales.ts
// Run with: tsx scripts/build-locales.ts
import { writeFile } from "node:fs/promises";
import { Langbly } from "langbly";
import en from "../messages/en.json";

const client = new Langbly({ apiKey: process.env.LANGBLY_API_KEY! });
const locales = ["nl", "de", "fr", "es", "ja"];
const source = en as Record<string, string>;

for (const locale of locales) {
  const entries = Object.entries(source);
  const translated = await Promise.all(
    entries.map(async ([key, value]) => {
      const result = await client.translate(value, { target: locale });
      return [key, result.translatedText] as const;
    })
  );

  await writeFile(
    `./messages/${locale}.json`,
    JSON.stringify(Object.fromEntries(translated), null, 2)
  );
}

Dynamic content (user posts, product descriptions, support replies) has to be translated at request time. Do it inside a Server Component so the key stays on the server and the browser gets finished HTML, with no loading spinner and no client bundle growth.

// app/[locale]/posts/[id]/page.tsx
import { translate } from "@/lib/translate";
import { getPost } from "@/lib/posts";

export default async function PostPage({
  params,
}: {
  params: Promise<{ locale: string; id: string }>;
}) {
  const { locale, id } = await params;
  const post = await getPost(id);

  const [title, body] = await Promise.all([
    translate(post.title, locale),
    translate(post.body, locale, "html"),
  ]);

  return (
    <article>
      <h1>{title}</h1>
      <div dangerouslySetInnerHTML={{ __html: body }} />
    </article>
  );
}

Note the format option in that second call. Setting it to "html" keeps your tags and attributes intact instead of translating the markup itself, which matters for rich text out of a CMS.

For i18n routing, the App Router pattern is a [locale] segment plus middleware that redirects a bare path to the visitor's preferred locale. Middleware runs on every request, so keep it to a header check and a redirect. Never call a translation API from middleware.

This is the mistake that turns a $5 bill into a $200 bill. Translation output is deterministic enough to cache, and the same product title will be requested thousands of times. There is no reason to pay for it more than once.

One catch specific to Next.js: the Data Cache only covers GET fetches. Translation calls are POSTs, so next: { revalidate } on the fetch does nothing. Wrap the call in unstable_cache instead and key it on the text plus the target locale.

// lib/translate.ts
import { unstable_cache } from "next/cache";

const ONE_MONTH = 60 * 60 * 24 * 30;

async function fetchTranslation(
  text: string,
  target: string,
  format: "text" | "html"
) {
  const response = await fetch(
    "https://api.langbly.com/language/translate/v2",
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Authorization: "Bearer " + process.env.LANGBLY_API_KEY,
      },
      body: JSON.stringify({ q: text, target, format }),
      cache: "no-store",
    }
  );

  if (!response.ok) {
    throw new Error("Translation failed: " + response.status);
  }

  const json = await response.json();
  return json.data.translations[0].translatedText as string;
}

export function translate(
  text: string,
  target: string,
  format: "text" | "html" = "text"
) {
  return unstable_cache(
    () => fetchTranslation(text, target, format),
    ["translate", target, format, text],
    { revalidate: ONE_MONTH, tags: ["translations"] }
  )();
}

Three habits worth building on top of this:

• Skip the call entirely when the source locale and the target locale match. It sounds obvious and it is missed constantly.
• Batch related strings into one request rather than firing one request per string. Fewer round trips, less rate-limit pressure.
• Store translations you intend to keep in your own database, and use the API only for cache misses. Then call revalidateTag("translations") when the source content changes.

• Best Translation API for JavaScript & Node.js
• Best Translation API for Python
• Langbly Quickstart: your first translation in 2 minutes
• Supported languages (100+)
• Try Langbly. 500K characters/month included