# How to Use IronPDF with GitHub Copilot
Most guides to AI-assisted coding assume you are willing to change editors. For .NET work that assumption is often wrong. A large share of IronPDF projects live in Visual Studio, inside solutions with project references, NuGet configuration, and a build pipeline nobody wants to relocate for the sake of trying an assistant.
GitHub Copilot runs where those projects already are, in Visual Studio, VS Code, and JetBrains IDEs, so this workflow needs no migration. It also does something no editor-only assistant can: it runs inside GitHub itself. You can describe a PDF problem in an issue, assign it to Copilot's coding agent, and get back a pull request. IronPDF renders HTML, CSS, and JavaScript to PDF through an embedded Chromium engine, and there is no integration between the two products. What connects them is the repository, and the conventions you commit to it.
One distinction first, because two similar topics compete. This guide is about using an AI coding assistant to *build software* with IronPDF. It is not about using AI models to read or analyze PDF content, which the [AI-powered PDF processing tutorial](/tutorials/ai-powered-pdf-processing-csharp/) covers separately.
*as-heading:2(Quickstart)*
!!!--LIBRARY_NUGET_INSTALL_BLOCK--!!!
Open the solution in whichever IDE it already lives in, and ask for the document:
```text
In this C# console project, create Program.cs that uses IronPDF to render
"<h1>Hello from IronPDF</h1>" to hello.pdf. Read the license key from the
IRONPDF_LICENSE_KEY environment variable, never inline. Then build and fix
any errors.
```
Copilot writes the handful of lines that matter, constructing a `ChromePdfRenderer`, calling `RenderHtmlAsPdf`, and saving the result with `SaveAs`. That part is unremarkable, and it is not why this guide exists. What follows is: the same assistant will do this work with nobody watching, on a branch, as a pull request, and that changes what you have to set up.
Two safety notes, both short. A license key never belongs inline in a prompt or a commit; it lives in configuration, an environment variable, or a repository secret, as the [license key guide](/get-started/license-keys/) describes. And an agent with repository write access opens real pull requests, so branch protection and human review remain the control that matters.
<div class="hsg-featured-snippet">
<h3>Minimal Workflow (5 steps)</h3>
<ol>
<li><a class="js-modal-open" data-modal-id="trial-license-after-download" href="https://www.nuget.org/packages/IronPdf/">Download the C# PDF library from NuGet</a></li>
<li>Commit <code>.github/copilot-instructions.md</code> with the project's IronPDF conventions</li>
<li>Use inline chat for small edits and agent mode for multi-file work</li>
<li>For unsupervised work, file a detailed issue and assign it to the coding agent</li>
<li>Review the pull request, checking every API name against the <a href="/object-reference/api/">API reference</a></li>
</ol>
</div>
<br class="clear" />
---
## Where does Copilot fit a project already in Visual Studio?
Copilot works at three ranges, and picking the right one saves more time than any prompt technique.
**Inline completions and chat** handle anything you could describe in a sentence and that lives in a single file: adjusting a margin, adding a footer to an existing renderer call, renaming a helper. You describe the change, you get a diff in place, you accept or you do not.
**Agent mode** handles work spanning several files, where Copilot decides which files to edit, runs terminal commands, reads the output, and iterates on errors. This is the right range for a migration or a refactor.
**The coding agent on GitHub** handles work that needs no supervision at all. You assign an issue, it plans, pushes a branch, and opens a pull request. This is what makes Copilot different from an editor-bound assistant, and it is where the rest of this guide spends its attention.
Copilot is a reasonable reader too. Asking it to explain the rendering options type and list which ones the project currently sets turns [the API reference](/object-reference/api/) into something you can query rather than scroll.
[[i:(The three ranges have different blast radii. An inline edit is reviewed before it lands, agent mode is reviewed as a diff, and the coding agent's work arrives as a pull request that can sit for a day before anyone reads it. Match the range to how much you want to be holding when it finishes.)]]
## How do you commit conventions every surface follows?
Repository custom instructions are committed to the repository, which means they govern IDE suggestions and the autonomous agent alike, including when the agent works with nobody watching. Write them once, then stop repeating yourself in prompts.
The file is `.github/copilot-instructions.md`. For a .NET team this is the format worth standardising on, because it is the one Visual Studio documents loading, alongside VS Code, JetBrains, the coding agent, and Copilot code review. Copilot reads other instruction files too, `AGENTS.md` among them, but support varies by surface in a way that changes release to release, so the safest default for a Visual Studio shop is the file named after the product.
```text
# Copilot instructions
## PDF generation
- Use IronPDF for all PDF generation. Use ChromePdfRenderer for HTML conversion.
- Target the IronPDF version pinned in Directory.Packages.props. Do not upgrade
it as part of an unrelated change.
- Never inline a license key. Read it from configuration or the
IRONPDF_LICENSE_KEY environment variable.
- Prefer the shared PdfDocumentService helper over constructing a renderer per
call. A ChromePdfRenderer instance is reusable.
- Use the async rendering methods in web request paths.
- Do not invent IronPDF API names. If a method is uncertain, say so and cite the
documentation rather than guessing.
## Testing
- Assert on extracted text, page count and the %PDF- signature.
- Never use golden-file byte comparisons; rendering output is not byte-stable.
```
The line about admitting uncertainty earns its place. A model's default is to produce something plausible-shaped rather than concede a gap, and inventing `renderer.ConvertHtmlToPdfDocument()` reads perfectly well right up until the compiler disagrees. Giving permission to stop is cheap, and it works.
Path-specific instructions in `.github/instructions/**/*.instructions.md` scope guidance to matching files, which keeps PDF conventions out of requests that have nothing to do with PDFs.
## What makes an issue the agent can actually act on?
Here the skill that matters is not prompt-writing. It is issue-writing, because the issue body is the entire brief the agent receives. Nobody is present to clarify it.
A weak issue looks like this:
```text
Title: PDF looks wrong
The invoice PDF doesn't look right. Can we fix the layout?
```
The agent has no file to open, no idea which of several PDFs is meant, no description of correct output, and no error to work from. It will explore, guess, and produce a pull request that may address the wrong thing entirely.
A strong issue carries everything a colleague would need:
```text
Title: Invoice PDF splits table rows across pages and drops the logo
**Files:** Services/InvoiceRenderer.cs, Templates/invoice.html
**IronPDF version:** as pinned in Directory.Packages.props
**Framework:** .NET 8
**Expected:** A4 portrait, 20mm margins. Line-item table rows stay intact
across page breaks. Company logo renders in the header.
**Actual:** A table row splits between pages 1 and 2. The logo area is blank
in the PDF but renders correctly when Templates/invoice.html is opened in
Chrome. No exception is thrown.
**Constraints:** Fix page-break behaviour in CSS, not in C#. Keep the public
signature of InvoiceRenderer.RenderAsync unchanged. No new packages.
**Acceptance:** Existing tests pass, plus a new test asserting page count for
the fixture in TestData/invoice-12-items.json.
```
Six things separate the second from the first: named files, the framework and library version, the expected output stated concretely, the actual behaviour including what does *not* happen, hard constraints, and a definition of done.
That detail about no exception being thrown is doing real work. It tells the agent this is a rendering problem rather than a crash, which rules out an entire category of investigation before it starts. The observation that the logo renders in Chrome but not in the PDF narrows it further: a raw HTML string carries no document location, so relative image paths have nothing to resolve against, while a browser knows where the page came from.
Once assigned, the agent plans, pushes a branch, opens a pull request, and requests review. You review the diff rather than watch the work.
## Why do the agent's tests fail on an IronPDF project?
This is the section no general Copilot guide will write, and it is the one most likely to save you an afternoon.
The coding agent builds and tests in its own ephemeral environment. For most projects, source plus a package restore is enough. An IronPDF project needs more, because rendering depends on a Chromium engine with native platform dependencies. If those are absent from the agent's Linux runner, every test that renders a PDF fails, for reasons that have nothing to do with the code the agent just wrote.
The consequence is worse than a red build. The agent sees failing tests, assumes its own change caused them, and starts modifying code that was already correct. It can work at that for a long time.
The fix is to preconfigure the environment with `.github/workflows/copilot-setup-steps.yml`. It looks like an ordinary GitHub Actions workflow with two rules that are easy to miss: the job must be named `copilot-setup-steps`, and the file will not trigger at all unless it exists on your repository's default branch.
```text
name: "Copilot Setup Steps"
on:
workflow_dispatch:
push:
paths:
- .github/workflows/copilot-setup-steps.yml
pull_request:
paths:
- .github/workflows/copilot-setup-steps.yml
jobs:
# The job MUST be called `copilot-setup-steps` or Copilot will not pick it up.
copilot-setup-steps:
runs-on: ubuntu-latest
permissions:
contents: read
steps:
- uses: actions/checkout@v4
- uses: actions/setup-dotnet@v4
with:
dotnet-version: '8.0.x'
# Install the native dependencies IronPDF's Chromium engine needs on
# Debian-based images. Take the current package list from the Docker
# and Linux deployment guide rather than copying one from anywhere else,
# because it changes between releases.
- name: Install IronPDF native dependencies
run: |
sudo apt-get update
sudo apt-get install -y <packages from the IronPDF Linux guide>
- run: dotnet restore
```
Two details decide whether this works.
First, a license key is not automatically available to the agent. Repository and organization secrets are not inherited by an agent session, so the key has to be added to the Copilot environment in the repository's settings separately.
Second, and this is the one that produces the confusing symptom: **if a setup step fails, Copilot does not stop.** It skips the remaining steps and begins working with whatever state the environment is in. A silently failed dependency install therefore looks exactly like a code problem. Run the workflow manually from the Actions tab once before relying on it.
[[t:(The practical rule: when a coding agent pull request has failing render tests on an IronPDF project, check the environment before you assume the change is wrong. The [Docker deployment guide](/get-started/ironpdf-docker/) documents the dependencies, which change between releases and should be read rather than recalled.)]]
## What should you check before merging?
The pull request is the review surface, and the same standards apply as to any colleague's branch. Copilot's own code review can run as a second pass over the agent's output, which catches mechanical issues before a human reads the diff.
Three checks matter specifically for IronPDF changes:
1. **Does every API name appear in the documentation,** or did something plausible slip through?
2. **Does the generated PDF actually look right?** No automated check will tell you, and a clean build says nothing about layout.
3. **Did the change stay inside the constraints the issue set?** Agents given a free hand tend to treat a bug fix as an invitation to redesign the calling convention.
Requesting tests in the same pull request is worth making standard:
```text
Add xUnit tests for this change: output is non-empty, begins with the %PDF-
signature, extracted text contains the bound company name, and page count
matches the fixture. No golden-file byte comparisons.
```
Ruling out byte comparison prevents a class of flaky test that would otherwise cost an afternoon, since rendering output differs across engine versions and platforms.
## When is it the code, and when is it the container?
Rendering differences between browser and PDF are the most common IronPDF question, and they usually come down to one of three causes: a stylesheet written for screen rather than print media, a web font that had not loaded when the layout was computed, or content produced by JavaScript that was captured too early. All three are code-side, and all three are worth naming in the request:
```text
Templates/report.html renders correctly in Chrome but the PDF splits a table
row across pages and the totals block lands on the next page alone.
Explain the cause before changing anything, then fix it in the CSS using page
break properties. Do not modify ReportRenderer.cs.
```
Asking for a diagnosis before a change gives you something to evaluate rather than a fix to reverse-engineer. Page-break behaviour belongs in the stylesheet, and the [page breaks guide](/how-to/html-to-pdf-page-breaks/) covers the relevant properties. Constraining the change to CSS keeps an agent from solving a layout problem by restructuring the C#.
The other half of the question is the one the previous section answered: when the same code renders locally and fails in a container or on a runner, it is usually not the code at all. Paste the full exception rather than paraphrasing it, and point the request at the Dockerfile rather than the application. A missing shared library is not a C# problem, and an agent given a free hand will sometimes wrap the call in a try/catch that hides the failure instead of fixing it.
## What keeps working when nobody is watching?
Two things, and they are the two worth setting up first. Committed instructions in `.github/copilot-instructions.md` govern the agent on a branch at midnight exactly as they govern your IDE at midday. A `copilot-setup-steps.yml` that installs IronPDF's native dependencies is what stops that same agent from spending its run debugging code that was never broken. Everything else is ordinary assistant usage that happens to work better once those two exist.
The verification habit does not change with the range: build early, open the PDF, and check the API names against the documentation before anything ships. The reproducible version of that check, run start to finish with a published result, lives on the [AI coding assistants guide](/ai-agents/ai/), alongside the guides for [Claude Code](/ai-agents/claude-code/), [ChatGPT Codex](/ai-agents/chatgpt-codex/), and [Cursor](/ai-agents/cursor/).
---
## Troubleshooting
- [Apply a license key in IronPDF](/troubleshooting/apply-a-license-key-in-ironpdf/): if generated code produces watermarked output
- [Initializing RenderingOptions Correctly](/troubleshooting/rendering-options-initialization/): if a suggested option name does not resolve
- [What version of IronPDF should I use?](/troubleshooting/what-version-of-ironpdf-should-i-use/): to pin a version in your instructions file
- [How to Run IronPDF in a Docker Container](/get-started/ironpdf-docker/): for the native dependencies the agent's runner needs
---
## Questions?
If you have any questions, reach out to [support@ironsoftware.com](mailto:support@ironsoftware.com)
Most guides to AI-assisted coding assume you are willing to change editors. For .NET work that assumption is often wrong. A large share of IronPDF projects live in Visual Studio, inside solutions with project references, NuGet configuration, and a build pipeline nobody wants to relocate for the sake of trying an assistant.
GitHub Copilot runs where those projects already are, in Visual Studio, VS Code, and JetBrains IDEs, so this workflow needs no migration. It also does something no editor-only assistant can: it runs inside GitHub itself. You can describe a PDF problem in an issue, assign it to Copilot's coding agent, and get back a pull request. IronPDF renders HTML, CSS, and JavaScript to PDF through an embedded Chromium engine, and there is no integration between the two products. What connects them is the repository, and the conventions you commit to it.
One distinction first, because two similar topics compete. This guide is about using an AI coding assistant to build software with IronPDF. It is not about using AI models to read or analyze PDF content, which the AI-powered PDF processing tutorial covers separately.
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 the solution in whichever IDE it already lives in, and ask for the document:
In this C# console project, create Program.cs that uses IronPDF to render"<h1>Hello from IronPDF</h1>" to hello.pdf. Read the license key from theIRONPDF_LICENSE_KEY environment variable, never inline. Then build and fixany errors.
In this C# console project, create Program.cs that uses IronPDF to render
"<h1>Hello from IronPDF</h1>" to hello.pdf. Read the license key from the
IRONPDF_LICENSE_KEY environment variable, never inline. Then build and fix
any errors.
Text
Copilot writes the handful of lines that matter, constructing a ChromePdfRenderer, calling RenderHtmlAsPdf, and saving the result with SaveAs. That part is unremarkable, and it is not why this guide exists. What follows is: the same assistant will do this work with nobody watching, on a branch, as a pull request, and that changes what you have to set up.
Two safety notes, both short. A license key never belongs inline in a prompt or a commit; it lives in configuration, an environment variable, or a repository secret, as the license key guide describes. And an agent with repository write access opens real pull requests, so branch protection and human review remain the control that matters.
Commit .github/copilot-instructions.md with the project's IronPDF conventions
Use inline chat for small edits and agent mode for multi-file work
For unsupervised work, file a detailed issue and assign it to the coding agent
Review the pull request, checking every API name against the API reference
Where does Copilot fit a project already in Visual Studio?
Copilot works at three ranges, and picking the right one saves more time than any prompt technique.
Inline completions and chat handle anything you could describe in a sentence and that lives in a single file: adjusting a margin, adding a footer to an existing renderer call, renaming a helper. You describe the change, you get a diff in place, you accept or you do not.
Agent mode handles work spanning several files, where Copilot decides which files to edit, runs terminal commands, reads the output, and iterates on errors. This is the right range for a migration or a refactor.
The coding agent on GitHub handles work that needs no supervision at all. You assign an issue, it plans, pushes a branch, and opens a pull request. This is what makes Copilot different from an editor-bound assistant, and it is where the rest of this guide spends its attention.
Copilot is a reasonable reader too. Asking it to explain the rendering options type and list which ones the project currently sets turns the API reference into something you can query rather than scroll.
Please note: The three ranges have different blast radii. An inline edit is reviewed before it lands, agent mode is reviewed as a diff, and the coding agent's work arrives as a pull request that can sit for a day before anyone reads it. Match the range to how much you want to be holding when it finishes.
How do you commit conventions every surface follows?
Repository custom instructions are committed to the repository, which means they govern IDE suggestions and the autonomous agent alike, including when the agent works with nobody watching. Write them once, then stop repeating yourself in prompts.
The file is .github/copilot-instructions.md. For a .NET team this is the format worth standardising on, because it is the one Visual Studio documents loading, alongside VS Code, JetBrains, the coding agent, and Copilot code review. Copilot reads other instruction files too, AGENTS.md among them, but support varies by surface in a way that changes release to release, so the safest default for a Visual Studio shop is the file named after the product.
# Copilot instructions## PDF generation- Use IronPDF for all PDF generation. Use ChromePdfRenderer for HTML conversion.- Target the IronPDF version pinned in Directory.Packages.props. Do not upgrade it as part of an unrelated change.- Never inline a license key. Read it from configuration or the IRONPDF_LICENSE_KEY environment variable.- Prefer the shared PdfDocumentService helper over constructing a renderer per call. A ChromePdfRenderer instance is reusable.- Use the async rendering methods in web request paths.- Do not invent IronPDF API names. If a method is uncertain, say so and cite the documentation rather than guessing.## Testing- Assert on extracted text, page count and the %PDF- signature.- Never use golden-file byte comparisons; rendering output is not byte-stable.
# Copilot instructions
## PDF generation
- Use IronPDF for all PDF generation. Use ChromePdfRenderer for HTML conversion.
- Target the IronPDF version pinned in Directory.Packages.props. Do not upgrade
it as part of an unrelated change.
- Never inline a license key. Read it from configuration or the
IRONPDF_LICENSE_KEY environment variable.
- Prefer the shared PdfDocumentService helper over constructing a renderer per
call. A ChromePdfRenderer instance is reusable.
- Use the async rendering methods in web request paths.
- Do not invent IronPDF API names. If a method is uncertain, say so and cite the
documentation rather than guessing.
## Testing
- Assert on extracted text, page count and the %PDF- signature.
- Never use golden-file byte comparisons; rendering output is not byte-stable.
Text
The line about admitting uncertainty earns its place. A model's default is to produce something plausible-shaped rather than concede a gap, and inventing renderer.ConvertHtmlToPdfDocument() reads perfectly well right up until the compiler disagrees. Giving permission to stop is cheap, and it works.
Path-specific instructions in .github/instructions/**/*.instructions.md scope guidance to matching files, which keeps PDF conventions out of requests that have nothing to do with PDFs.
What makes an issue the agent can actually act on?
Here the skill that matters is not prompt-writing. It is issue-writing, because the issue body is the entire brief the agent receives. Nobody is present to clarify it.
A weak issue looks like this:
Title: PDF looks wrongThe invoice PDF doesn't look right. Can we fix the layout?
Title: PDF looks wrong
The invoice PDF doesn't look right. Can we fix the layout?
Text
The agent has no file to open, no idea which of several PDFs is meant, no description of correct output, and no error to work from. It will explore, guess, and produce a pull request that may address the wrong thing entirely.
A strong issue carries everything a colleague would need:
Title: Invoice PDF splits table rows across pages and drops the logo**Files:** Services/InvoiceRenderer.cs, Templates/invoice.html**IronPDF version:** as pinned in Directory.Packages.props**Framework:** .NET 8**Expected:** A4 portrait, 20mm margins. Line-item table rows stay intactacross page breaks. Company logo renders in the header.**Actual:** A table row splits between pages 1 and 2. The logo area is blankin the PDF but renders correctly when Templates/invoice.html is opened inChrome. No exception is thrown.**Constraints:** Fix page-break behaviour in CSS, not in C#. Keep the publicsignature of InvoiceRenderer.RenderAsync unchanged. No new packages.**Acceptance:** Existing tests pass, plus a new test asserting page count forthe fixture in TestData/invoice-12-items.json.
Title: Invoice PDF splits table rows across pages and drops the logo
**Files:** Services/InvoiceRenderer.cs, Templates/invoice.html
**IronPDF version:** as pinned in Directory.Packages.props
**Framework:** .NET 8
**Expected:** A4 portrait, 20mm margins. Line-item table rows stay intact
across page breaks. Company logo renders in the header.
**Actual:** A table row splits between pages 1 and 2. The logo area is blank
in the PDF but renders correctly when Templates/invoice.html is opened in
Chrome. No exception is thrown.
**Constraints:** Fix page-break behaviour in CSS, not in C#. Keep the public
signature of InvoiceRenderer.RenderAsync unchanged. No new packages.
**Acceptance:** Existing tests pass, plus a new test asserting page count for
the fixture in TestData/invoice-12-items.json.
Text
Six things separate the second from the first: named files, the framework and library version, the expected output stated concretely, the actual behaviour including what does not happen, hard constraints, and a definition of done.
That detail about no exception being thrown is doing real work. It tells the agent this is a rendering problem rather than a crash, which rules out an entire category of investigation before it starts. The observation that the logo renders in Chrome but not in the PDF narrows it further: a raw HTML string carries no document location, so relative image paths have nothing to resolve against, while a browser knows where the page came from.
Once assigned, the agent plans, pushes a branch, opens a pull request, and requests review. You review the diff rather than watch the work.
Why do the agent's tests fail on an IronPDF project?
This is the section no general Copilot guide will write, and it is the one most likely to save you an afternoon.
The coding agent builds and tests in its own ephemeral environment. For most projects, source plus a package restore is enough. An IronPDF project needs more, because rendering depends on a Chromium engine with native platform dependencies. If those are absent from the agent's Linux runner, every test that renders a PDF fails, for reasons that have nothing to do with the code the agent just wrote.
The consequence is worse than a red build. The agent sees failing tests, assumes its own change caused them, and starts modifying code that was already correct. It can work at that for a long time.
The fix is to preconfigure the environment with .github/workflows/copilot-setup-steps.yml. It looks like an ordinary GitHub Actions workflow with two rules that are easy to miss: the job must be named copilot-setup-steps, and the file will not trigger at all unless it exists on your repository's default branch.
name: "Copilot Setup Steps"on: workflow_dispatch: push: paths: - .github/workflows/copilot-setup-steps.yml pull_request: paths: - .github/workflows/copilot-setup-steps.ymljobs: # The job MUST be called `copilot-setup-steps` or Copilot will not pick it up. copilot-setup-steps: runs-on: ubuntu-latest permissions: contents: read steps: - uses: actions/checkout@v4 - uses: actions/setup-dotnet@v4 with: dotnet-version: '8.0.x' # Install the native dependencies IronPDF's Chromium engine needs on # Debian-based images. Take the current package list from the Docker # and Linux deployment guide rather than copying one from anywhere else, # because it changes between releases. - name: Install IronPDF native dependencies run: | sudo apt-get update sudo apt-get install -y <packages from the IronPDF Linux guide> - run: dotnet restore
name: "Copilot Setup Steps"
on:
workflow_dispatch:
push:
paths:
- .github/workflows/copilot-setup-steps.yml
pull_request:
paths:
- .github/workflows/copilot-setup-steps.yml
jobs:
# The job MUST be called `copilot-setup-steps` or Copilot will not pick it up.
copilot-setup-steps:
runs-on: ubuntu-latest
permissions:
contents: read
steps:
- uses: actions/checkout@v4
- uses: actions/setup-dotnet@v4
with:
dotnet-version: '8.0.x'
# Install the native dependencies IronPDF's Chromium engine needs on
# Debian-based images. Take the current package list from the Docker
# and Linux deployment guide rather than copying one from anywhere else,
# because it changes between releases.
- name: Install IronPDF native dependencies
run: |
sudo apt-get update
sudo apt-get install -y <packages from the IronPDF Linux guide>
- run: dotnet restore
Text
Two details decide whether this works.
First, a license key is not automatically available to the agent. Repository and organization secrets are not inherited by an agent session, so the key has to be added to the Copilot environment in the repository's settings separately.
Second, and this is the one that produces the confusing symptom: if a setup step fails, Copilot does not stop. It skips the remaining steps and begins working with whatever state the environment is in. A silently failed dependency install therefore looks exactly like a code problem. Run the workflow manually from the Actions tab once before relying on it.
Tips: The practical rule: when a coding agent pull request has failing render tests on an IronPDF project, check the environment before you assume the change is wrong. The Docker deployment guide documents the dependencies, which change between releases and should be read rather than recalled.
What should you check before merging?
The pull request is the review surface, and the same standards apply as to any colleague's branch. Copilot's own code review can run as a second pass over the agent's output, which catches mechanical issues before a human reads the diff.
Three checks matter specifically for IronPDF changes:
Does every API name appear in the documentation, or did something plausible slip through?
Does the generated PDF actually look right? No automated check will tell you, and a clean build says nothing about layout.
Did the change stay inside the constraints the issue set? Agents given a free hand tend to treat a bug fix as an invitation to redesign the calling convention.
Requesting tests in the same pull request is worth making standard:
Add xUnit tests for this change: output is non-empty, begins with the %PDF-signature, extracted text contains the bound company name, and page countmatches the fixture. No golden-file byte comparisons.
Add xUnit tests for this change: output is non-empty, begins with the %PDF-
signature, extracted text contains the bound company name, and page count
matches the fixture. No golden-file byte comparisons.
Text
Ruling out byte comparison prevents a class of flaky test that would otherwise cost an afternoon, since rendering output differs across engine versions and platforms.
When is it the code, and when is it the container?
Rendering differences between browser and PDF are the most common IronPDF question, and they usually come down to one of three causes: a stylesheet written for screen rather than print media, a web font that had not loaded when the layout was computed, or content produced by JavaScript that was captured too early. All three are code-side, and all three are worth naming in the request:
Templates/report.html renders correctly in Chrome but the PDF splits a tablerow across pages and the totals block lands on the next page alone.Explain the cause before changing anything, then fix it in the CSS using pagebreak properties. Do not modify ReportRenderer.cs.
Templates/report.html renders correctly in Chrome but the PDF splits a table
row across pages and the totals block lands on the next page alone.
Explain the cause before changing anything, then fix it in the CSS using page
break properties. Do not modify ReportRenderer.cs.
Text
Asking for a diagnosis before a change gives you something to evaluate rather than a fix to reverse-engineer. Page-break behaviour belongs in the stylesheet, and the page breaks guide covers the relevant properties. Constraining the change to CSS keeps an agent from solving a layout problem by restructuring the C#.
The other half of the question is the one the previous section answered: when the same code renders locally and fails in a container or on a runner, it is usually not the code at all. Paste the full exception rather than paraphrasing it, and point the request at the Dockerfile rather than the application. A missing shared library is not a C# problem, and an agent given a free hand will sometimes wrap the call in a try/catch that hides the failure instead of fixing it.
What keeps working when nobody is watching?
Two things, and they are the two worth setting up first. Committed instructions in .github/copilot-instructions.md govern the agent on a branch at midnight exactly as they govern your IDE at midday. A copilot-setup-steps.yml that installs IronPDF's native dependencies is what stops that same agent from spending its run debugging code that was never broken. Everything else is ordinary assistant usage that happens to work better once those two exist.
The verification habit does not change with the range: build early, open the PDF, and check the API names against the documentation before anything ships. The reproducible version of that check, run start to finish with a published result, lives on the AI coding assistants guide, alongside the guides for Claude Code, ChatGPT Codex, and Cursor.
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.
Install with NuGet
