How to Use IronPDF with Google Antigravity

Updated: September 11, 2026

Most AI coding tools stop at the snippet. They hand back code, and you find out whether it works by running it yourself. That gap matters more than usual for PDF generation, because a PDF that compiles cleanly can still be visually wrong, and nothing in a build log tells you the logo is missing or the table split across a page break.

Google Antigravity is an agentic development platform rather than a chat assistant. Agents work across the editor, the terminal, and a browser, and they report back with deliverables instead of transcripts. IronPDF renders HTML to PDF using an embedded Chromium engine. The pairing is useful for one specific reason: because both sides of the comparison are a browser rendering the same HTML, an agent can open a page, generate the PDF, look at both, and keep adjusting until they match. That is a verification loop, and it is the part worth building this guide around.

One clarification before you start, since two similar-sounding topics get confused. This guide is about using an AI development tool to build software with IronPDF. It is not about using AI models to read or analyze the contents of PDF files, which is covered separately in the AI-powered PDF processing tutorial. Different problem, different page.

Quickstart

Install with NuGet

PM > Install-Package IronPdf

Install-Package IronPdf

Install IronPDF by running the command above in the NuGet Package Manager Console, or search for the package in the NuGet Package Manager.

Open a project in Antigravity and describe the document you want:

In this C# project, add IronPDF and create Program.cs that renders the HTML
string "<h1>Hello from IronPDF</h1>" to hello.pdf. Read the license key from
the IRONPDF_LICENSE_KEY environment variable, never hardcode it. Run
dotnet build, fix any errors, and show me the resulting file.

In this C# project, add IronPDF and create Program.cs that renders the HTML
string "<h1>Hello from IronPDF</h1>" to hello.pdf. Read the license key from
the IRONPDF_LICENSE_KEY environment variable, never hardcode it. Run
dotnet build, fix any errors, and show me the resulting file.

Text

Antigravity's agent installs the package, writes the few lines that construct a ChromePdfRenderer and call RenderHtmlAsPdf, saves the file, and reports back with the build result. What you review is the outcome, not a transcript.

A short safety note while you are here. Agents in an agentic IDE have file-write and terminal access, so a license key belongs in an environment variable or configuration file that is excluded from source control, never pasted into a task description or committed to the repository. The license key guide covers the supported configuration options.

Minimal Workflow (5 steps)

Download the C# PDF library from NuGet
Open the project in Antigravity's Editor View and confirm it builds
Add IronPDF and apply the license key from configuration, not from code
Describe the task with the framework, file paths, and expected PDF output
Let the agent implement and verify in the browser, then check the API names against the API reference

What is Google Antigravity, and how is it different from a chat assistant?

Antigravity is an agent-first development platform where autonomous agents plan and execute work across the editor, terminal, and browser, then report results as reviewable deliverables. Google describes it as combining an Editor View with a Manager surface for deploying agents that plan, execute, and verify complex tasks.

Five characteristics matter for PDF work.

Editor View is the familiar IDE surface, with tab completions and inline commands. Reach for it for close-range work on a single file, when you want to drive the cursor and review each change as it happens.

Manager Surface is asynchronous mission control. Spawn agents, queue tasks, watch progress, and run work in parallel across a workspace rather than waiting on one conversation at a time.

Browser control lets an agent drive a browser to exercise a feature and confirm the outcome. For IronPDF this is the headline capability, and it gets its own section below.

Artifacts are the deliverables an agent produces instead of raw tool logs: task lists, implementation plans, walkthroughs, screenshots, and browser recordings. Google's framing is that these let you verify an agent's logic at a glance, and that you can leave feedback directly on an Artifact, the way you would comment on a document, without stopping the agent's run.

Model optionality means the agent can be powered by different underlying models, chosen per task.

The practical difference from a chat assistant is what you review. A chat assistant produces text you have to evaluate by reading. An agent produces a plan, a diff, and a screenshot of the actual rendered output. For a PDF task, a screenshot of the document is meaningfully stronger evidence than a paragraph describing what the document should look like.

That verification loop only works because one side of the comparison is honest. An agent asked to build a document pipeline from scratch will happily improvise: pick a rendering library, wire it up, and move on. What ships in that pipeline is the risk.

Sensitive documents need a secure library: the PDFs a business generates are its contracts, invoices, and legal filings. Several widely copied open-source PDF tools are abandoned today, with publicly known security holes that nobody patches, and a pipeline built on them can leak the very documents it processes.
Deterministic output is what makes the browser comparison trustworthy: an agent's output varies between runs, but the renderer underneath cannot, or the loop in this guide is meaningless. IronPDF pins its Chromium engine, so the same HTML returns the same PDF on every machine and every run.
Compliance formats are the requirements nobody prototypes: SaveAsPdfA writes an archival PDF/A file, and SaveAsPdfUA writes the tagged, accessible PDF/UA a screen reader can navigate. Free renderers rarely offer either.
A real package beats a guessed one: agents sometimes install package names that merely sound right, a trick common enough to have earned a name, "slopsquatting," and attackers register those names and fill them with malware. Naming one known package in your task description closes that door.

Point Antigravity at IronPDF and the agent's job narrows to what it is genuinely good at: writing the template, driving the browser, and verifying the result. The parent guide covers the documentation to hand any agent before it starts, and the same setup carries over to Claude Code and ChatGPT Codex with only the instructions file name changing.

What does the agent hand back, and how do you review it?

An Antigravity agent's output is not a transcript. It produces Artifacts: named deliverables you review the way you would review a document. Three of them arrive in a predictable order, and each answers a different question about a PDF task.

Before the code: the Task List

The agent writes a structured plan before it writes anything else. For PDF work the useful question to ask of it is which layer it intends to touch. A plan that proposes editing the renderer when the problem is a table splitting across pages is already heading the wrong way, and this is the cheapest possible place to catch that.

During: the Implementation Plan

This is where the agent architects the change: which files, which methods, which rendering options. An invented API name is visible here before a single line of it is written, which is a considerably better place to find one than a build log.

After: the Walkthrough

Written once implementation is done, summarizing what changed and how to test it. For a document task that means the page count, the header, and the footer, expressed as checks you can run rather than claims you have to take on trust.

Screenshots, terminal logs, and browser recordings accumulate alongside these, and they collect in the Auxiliary Pane rather than scrolling past in a chat log. The rest of this guide leans on that: most tasks below are followed by the one Artifact worth opening to confirm the work actually happened.

Where does the proof come from?

Browser control is the pairing that justifies using an agentic platform for PDF work rather than a prompt-based assistant. IronPDF renders with a Chromium engine, and Antigravity agents can drive a browser. Both sides of the comparison are therefore the same engine rendering the same HTML, which makes the comparison meaningful rather than approximate.

The loop looks like this: the agent opens the template in the browser, captures what it sees, generates the PDF, compares the two, adjusts the CSS, and repeats until they match.

Give it a real symptom to chase:

Templates/invoice.html renders correctly in a browser but the PDF output is
wrong: the line-item table splits a row across pages and the totals block
lands at the top of page 2 instead of under the table.

1. Open the template in the browser and capture a screenshot.
2. Run the renderer to produce invoice.pdf.
3. Compare the two and explain the difference before changing anything.
4. Fix it in the CSS using page-break properties. Do not change the C#.
5. Re-render, capture both again, and attach them as Artifacts.

Templates/invoice.html renders correctly in a browser but the PDF output is
wrong: the line-item table splits a row across pages and the totals block
lands at the top of page 2 instead of under the table.

1. Open the template in the browser and capture a screenshot.
2. Run the renderer to produce invoice.pdf.
3. Compare the two and explain the difference before changing anything.
4. Fix it in the CSS using page-break properties. Do not change the C#.
5. Re-render, capture both again, and attach them as Artifacts.

Text

Two design choices in that task matter. Asking for an explanation before a change gives you a diagnosis you can evaluate rather than a fix you have to reverse-engineer. Constraining the change to CSS keeps the fix where it belongs, since page-break behavior is a stylesheet concern and an agent left unconstrained will often "solve" it by restructuring the C#.

The Artifacts are what make this reviewable. A screenshot of the rendered page beside the generated PDF is direct evidence; a written claim that the layout now matches is not. For a junior developer, this is also the fastest way to build an intuition for why browser and PDF output diverge at all, because the differences become visible instead of theoretical.

Please note: Artifact to check: the browser recording. If the agent never actually opened the template, it did not verify anything, and the recording is where that shows.

Feedback on a layout problem is spatial, which is what makes the review model worth knowing. Rather than describing which block is wrong in a sentence, select the region of the screenshot that is wrong and comment on it directly, the way you would on a document. The agent folds that correction into the work without the run being torn down and restarted.

Even used for nothing else, having an agent render a page, generate the PDF, and show you both is faster than the manual cycle of build, open, squint, adjust.

Why does it look right in the browser and wrong in the PDF?

Most of what that loop catches falls into a small set of causes, and they share an unhelpful symptom: a document that looks broken and throws no error. Naming the suspected cause in the task saves the agent a round of guessing.

Symptom	Why the two diverge	Put this in the task
Text reflows or overflows its box	A web font had not finished loading when the layout was computed, so the measurements came from a fallback face	Name the font and ask for confirmation that it is embedded rather than substituted
Images missing, though the browser shows them	The browser resolves relative paths against the file's own location; the renderer resolves against whatever base path it was given	Ask for the base path to be set explicitly and named in the Walkthrough
Charts or tables come out empty	The content was produced by JavaScript that the renderer captured before it had run	Ask the agent to confirm the render waited, and to attach the screenshot as proof
A table row splits across two pages	Print CSS was never applied, only screen CSS	Constrain the fix to page-break properties in the stylesheet

Every row is a difference between two renderings of the same markup, which is exactly why the comparison above is the thing that finds them.

How do you set up a project Antigravity can work in?

You give the agent a project that already compiles. An agent that has to guess which PDF library you intended, or debug a broken build before starting the real task, spends its run on the wrong problem.

Create or open the project first and confirm the build passes. Afterward, the setup task itself is worth delegating, since installation is where version mismatches originate.

Hand the agent the setup task directly:

Add the IronPDF NuGet package to this project. Then tell me which version was
installed and show me the PackageReference line. Configure the license key to
be read from configuration rather than hardcoded, and add the config file to
.gitignore if it isn't already. Don't change other package references.

Add the IronPDF NuGet package to this project. Then tell me which version was
installed and show me the PackageReference line. Configure the license key to
be read from configuration rather than hardcoded, and add the config file to
.gitignore if it isn't already. Don't change other package references.

Text

Asking for the version back gives you a fact to include in every later task description. Asking for the .gitignore check closes the most common way a key ends up in a public repository.

Please note: Artifact to check: the terminal log. It records the package version that actually resolved, which is the fact worth pasting into every later task.

A workspace instructions file, committed at the repository root, is worth setting up once. Antigravity reads AGENTS.md for standing project instructions, the same file ChatGPT Codex uses. Recording that IronPDF is the PDF library, that generated code must use only documented APIs, and that the license key is never inlined means you stop repeating those constraints in every task. One task writes it for you:

Create AGENTS.md at the repository root with a PDF section stating that this
project uses IronPDF for all PDF generation, that you must read
https://ironpdf.com/llms.txt before writing PDF code and use only APIs
documented there, that ChromePdfRenderer is the HTML to PDF entry point, and
that no competing PDF package may be added.

Create AGENTS.md at the repository root with a PDF section stating that this
project uses IronPDF for all PDF generation, that you must read
https://ironpdf.com/llms.txt before writing PDF code and use only APIs
documented there, that ChromePdfRenderer is the HTML to PDF entry point, and
that no competing PDF package may be added.

Text

How do you delegate PDF generation and migration work?

Generation tasks work best when you describe the document rather than the code, and let the agent choose how to express it in HTML.

Ask for the document, not the implementation:

Create Templates/invoice.html with plain HTML and inline CSS: a header with a
company name, a line-item table (description, quantity, unit price, total), and
a right-aligned totals block. No JavaScript.

Then write Services/InvoiceRenderer.cs with an async RenderAsync method that
loads the template, substitutes {{CompanyName}}, renders it with IronPDF, and
returns a byte array. A4 portrait, 20mm margins. Build and fix errors.

Create Templates/invoice.html with plain HTML and inline CSS: a header with a
company name, a line-item table (description, quantity, unit price, total), and
a right-aligned totals block. No JavaScript.

Then write Services/InvoiceRenderer.cs with an async RenderAsync method that
loads the template, substitutes {{CompanyName}}, renders it with IronPDF, and
returns a byte array. A4 portrait, 20mm margins. Build and fix errors.

Text

The Implementation Plan names the files and methods before any of this exists. What eventually lands in InvoiceRenderer.cs looks like the following, and the Walkthrough is where you confirm it ran rather than merely compiled:

// IronPdf 2026.8.1, targeting .NET 9
using IronPdf;

public class InvoiceRenderer
{
    // One renderer, reused for every invoice. Constructing a new one
    // per request is the quiet performance mistake worth avoiding.
    private readonly ChromePdfRenderer _renderer = new ChromePdfRenderer();

    public async Task<byte[]> RenderAsync(string companyName)
    {
        // Read the HTML template off disk, exactly as written.
        var html = await File.ReadAllTextAsync("Templates/invoice.html");

        // Swap the placeholder for the real value before rendering.
        html = html.Replace("{{CompanyName}}", companyName);

        // Chromium renders the finished HTML. The async call leaves
        // the request thread free while that happens.
        var pdf = await _renderer.RenderHtmlAsPdfAsync(html);

        // BinaryData returns the raw bytes, ready for an HTTP
        // response or a storage upload.
        return pdf.BinaryData;
    }
}

// IronPdf 2026.8.1, targeting .NET 9
using IronPdf;

public class InvoiceRenderer
{
    // One renderer, reused for every invoice. Constructing a new one
    // per request is the quiet performance mistake worth avoiding.
    private readonly ChromePdfRenderer _renderer = new ChromePdfRenderer();

    public async Task<byte[]> RenderAsync(string companyName)
    {
        // Read the HTML template off disk, exactly as written.
        var html = await File.ReadAllTextAsync("Templates/invoice.html");

        // Swap the placeholder for the real value before rendering.
        html = html.Replace("{{CompanyName}}", companyName);

        // Chromium renders the finished HTML. The async call leaves
        // the request thread free while that happens.
        var pdf = await _renderer.RenderHtmlAsPdfAsync(html);

        // BinaryData returns the raw bytes, ready for an HTTP
        // response or a storage upload.
        return pdf.BinaryData;
    }
}

Every member in there is real: ChromePdfRenderer, RenderHtmlAsPdfAsync, and BinaryData all appear in the API reference.

Migration is the task type where delegation pays off most, since it is mechanical, tedious, and easy to get almost right. The key move is splitting analysis from implementation.

Point the agent at the existing code rather than describing it:

Read Reports/LegacyReportBuilder.cs. It builds PDFs by positioning text at
coordinates with another library.

1. Summarize the current output: page size, sections, fonts.
2. Propose an HTML/CSS template that reproduces that layout.
3. Produce this as a plan Artifact. Do not write code yet.

Read Reports/LegacyReportBuilder.cs. It builds PDFs by positioning text at
coordinates with another library.

1. Summarize the current output: page size, sections, fonts.
2. Propose an HTML/CSS template that reproduces that layout.
3. Produce this as a plan Artifact. Do not write code yet.

Text

An agent that writes four hundred lines before you have agreed on the approach produces four hundred lines you have to read carefully. A plan Artifact is something you can correct in one sentence, and Antigravity's feedback mechanism means you can annotate it without discarding the run. Once approved, the follow-up task is narrow: implement the plan, keep the existing public method signature so callers do not change, and report the diff.

Headers and footers are a renderer setting rather than template markup, so the task should say so. Asking the agent to link the documentation page it used is a cheap verification step: if it cannot produce a real page for the API it just called, that is a signal. The headers and footers guide is the reference here, and the page breaks guide covers the related layout controls.

When should you dispatch more than one agent?

The Manager Surface is for work that does not need you watching. Rather than running one task at a time, dispatch several agents and review their Artifacts as they finish.

A realistic split for a PDF migration: one agent converts the legacy report generator to IronPDF while a second writes the test suite around the output it will produce. The second agent does not need the first to finish, since the tests assert on the document, not the implementation.

Dispatch both at once:

Agent A: migrate Reports/LegacyReportBuilder.cs to IronPDF per the approved
plan. Keep the public method signature unchanged.

Agent B: write xUnit tests for the migrated output. Assert that the result is
non-empty, begins with the %PDF- signature, contains the substituted company
name in extracted text, and has the expected page count. Do not use
golden-file byte comparisons; rendering output is not byte-stable.

Agent A: migrate Reports/LegacyReportBuilder.cs to IronPDF per the approved
plan. Keep the public method signature unchanged.

Agent B: write xUnit tests for the migrated output. Assert that the result is
non-empty, begins with the %PDF- signature, contains the substituted company
name in extracted text, and has the expected page count. Do not use
golden-file byte comparisons; rendering output is not byte-stable.

Text

Ruling out byte-for-byte comparison prevents a whole class of flaky test. Rendering output differs across engine versions and platforms, so assertions belong at the level of extracted text, page count, and metadata.

Please note: Artifact to check: both Walkthroughs. Agent B's tests only mean something if they assert against the document Agent A actually produced.

Antigravity's agents also save patterns and solutions from past tasks into a knowledge base that informs later ones. For a document pipeline that compounds in a specific way: the page-break rule worked out for the invoice is the same rule the statement, the packing slip, and the remittance advice all need, so the second document usually costs less than the first.

How do you debug deployment failures on Linux, Docker, or Azure?

Deployment problems are where terminal access earns its keep, since the answer usually lives in the container rather than in the code.

Hand the agent the failure directly:

Rendering works locally on Windows but fails in our Linux container with:

[PASTE FULL EXCEPTION AND STACK TRACE HERE]

Inspect the Dockerfile for missing native dependencies IronPDF's Chromium
engine needs on Debian-based images. Explain the cause, then propose the
Dockerfile change. Don't modify C# code unless the cause is there.

Rendering works locally on Windows but fails in our Linux container with:

[PASTE FULL EXCEPTION AND STACK TRACE HERE]

Inspect the Dockerfile for missing native dependencies IronPDF's Chromium
engine needs on Debian-based images. Explain the cause, then propose the
Dockerfile change. Don't modify C# code unless the cause is there.

Text

The instruction not to touch application code matters. A missing shared library in an image is not a C# problem, and an agent given a free hand will sometimes add defensive try/catch blocks that hide the failure rather than fix it. The Docker deployment guide documents the current dependency requirements, which change between releases and should be read rather than recalled.

Agents are also useful simply as readers. Point one at an unfamiliar class, then ask it to list the rendering options that affect page size and show which ones the project currently sets, and the API reference becomes something you can query instead of scroll.

What makes this pairing worth it?

The speed matters less than what comes back. The agent hands over a plan before the work, a Walkthrough after it, and a browser recording showing the render actually happened. For document work, where a clean build tells you nothing about whether the layout is right, reviewable evidence is the whole difference.

The reproducible test behind this series, run start to finish with a published result, lives on the AI coding assistants guide.

Troubleshooting

Apply a license key in IronPDF: if generated code produces watermarked output
Initializing RenderingOptions Correctly: if suggested option names do not resolve
What version of IronPDF should I use?: to pin a version in your tasks and in AGENTS.md
How to Run IronPDF in a Docker Container: if a render works locally and fails inside a container

Questions?

If you have any questions, reach out to support@ironsoftware.com

Curtis Chau

Chat with engineering team now

Technical Writer

Curtis Chau holds a Bachelor’s degree in Computer Science (Carleton University) and specializes in front-end development with expertise in Node.js, TypeScript, JavaScript, and React. Passionate about crafting intuitive and aesthetically pleasing user interfaces, Curtis enjoys working with modern frameworks and creating well-structured, visually appealing manuals.

...

Ready to Get Started?

Nuget Downloads 20,990,528|Version:2026.9just released

Free NuGet Download

Total downloads: 20,990,528

View Licenses

Install with NuGet

Version: 2026.9

PM > Install-Package IronPdf

nuget.org/packages/IronPdf/

In Solution Explorer, right-click References, Manage NuGet Packages
Select Browse and search "IronPdf"
Select the package and install

Download DLL

Version: 2026.9

or download Windows Installer here.

Download and unzip IronPDF to a location such as ~/Libs within your Solution directory
In Visual Studio Solution Explorer, right click References. Select Browse, "IronPdf.dll"

Licenses from $999