PDFPipe

Comparison

An Apache FOP alternative built on HTML and CSS

Apache FOP is a mature XML-to-PDF pipeline for enterprise Java applications. Developers who need to generate PDFs from dynamic HTML templates run into its biggest constraint quickly: FOP does not accept HTML. You write XSL-FO, a verbose XML page description language, and transform your data into it before FOP can render anything. PDFPipe takes HTML and CSS directly, through a REST API, with no Java runtime required.

How they compare

PDFPipeApache FOP
Input formatHTML and CSSXSL-FO (XML page description language)
Rendering engineFull browser rendering engineJava-based FOP renderer
Language / runtime requiredNone (REST API)Java runtime, XML/XSLT expertise
CSS supportFull: Grid, flexbox, web fonts, variablesBasic (no Grid, no flexbox)
URL-to-PDFYes, SSRF-sandboxedNo
Batch supportYes, dedicated batch endpointNo built-in batch API
Self-hosting requiredNo (managed API)Yes (server, ops, upgrades)
AI agent toolsFirst-class MCP serverNone

Send a request from Java

FOP users are typically on a JVM stack. The Java 11+ HTTP client makes the PDFPipe call straightforward. No new runtime, no additional dependency beyond a JSON string.

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpRequest.BodyPublishers;
import java.net.http.HttpResponse;
import java.nio.file.Files;
import java.nio.file.Path;

HttpClient client = HttpClient.newHttpClient();

String body = """
    {
      "html": "<h1>Invoice #1042</h1><p>Amount due: $250.00</p>",
      "options": { "format": "A4" }
    }
    """;

HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://api.pdfpipe.xyz/v1/pdf"))
    .header("Authorization", "Bearer pp_live_your_key")
    .header("Content-Type", "application/json")
    .POST(BodyPublishers.ofString(body))
    .build();

HttpResponse<byte[]> response = client.send(
    request, HttpResponse.BodyHandlers.ofByteArray()
);

Files.write(Path.of("invoice.pdf"), response.body());

When FOP is still the right choice

FOP makes sense when your pipeline already produces XSL-FO and swapping the renderer would require rewriting the entire transformation layer. It is also the right tool when strict XSL-FO compliance is a hard requirement, for example in regulated publishing workflows that mandate the XSL-FO specification as the interchange format. If neither of those applies, HTML plus a browser-rendering API is almost always faster to build and cheaper to run.

Try PDFPipe on the live playground with no signup, then read the docs.

See pricing →