This guide is published by ChangeThisFile and its conclusion is that you should probably keep paying PDFShift. That is not modesty - it is what the numbers say, and there is no version of this comparison where hiding them helps you.

PDFShift is a specialised HTML rendering service: you give it HTML, it gives you back a PDF, PNG, JPEG or WEBP. ChangeThisFile is a general format converter covering roughly 1,000 routes, and it renders HTML through LibreOffice. Those are different pieces of engineering, and for the job PDFShift does, PDFShift does it better and for less money.

Below: the real cost comparison, the one scenario where bringing ChangeThisFile in makes sense, and - if you have read all that and still want to move - the API mapping and code to do it.

Why you probably shouldn't migrate

PDFShift is cheaper. Not marginally - at every tier. Its entry plan is $9 for 500 conversions a month; the cheapest ChangeThisFile plan that does anything is $29 for 1,500. At 25,000 conversions PDFShift charges $99 and ChangeThisFile charges $499. See the table below for the full ladder.

PDFShift's free tier is bigger. 50 conversions a month, recurring, against ChangeThisFile's 25.

The rendering is not equivalent. PDFShift renders HTML the way a browser does. ChangeThisFile converts html to pdf through LibreOffice, which was built to lay out word-processor documents, not web pages. Flexbox, CSS Grid, JavaScript-rendered content, @font-face loading, print media queries and @page rules are where the difference shows, and it shows badly. For anything customer-facing - invoices, contracts, branded reports - this alone settles it.

PDFShift absorbs overages; ChangeThisFile doesn't. Every PDFShift plan bills extra credits above quota, from $0.04 each on Starter down to $0.001 at the top. ChangeThisFile hard-stops at quota and returns HTTP 429 for the rest of the billing period, so an unexpected spike fails rather than costing money.

You also lose features that have no equivalent - custom headers and footers, margin control, landscape and page-size options, passing a URL instead of a file, and webhooks.

The one case that isn't a migration

PDFShift accepts HTML and nothing else. It cannot ingest a DOCX, a spreadsheet, an image or a video, and it cannot read a PDF. So if your product needs to convert user-uploaded files, or turn a PDF back into DOCX, or transcode audio, that work was never running through PDFShift and cannot be migrated off it.

In that situation the sensible architecture is both: PDFShift keeps rendering your HTML templates, and a general converter handles the file formats it cannot accept. That is an addition to your stack, not a replacement, and it is the only scenario on this page where ChangeThisFile earns a place.

The narrow exception: if your HTML is genuinely plain - server-rendered tables and text with basic CSS, no JavaScript, no custom fonts - LibreOffice may render it acceptably, and if you are already paying for a ChangeThisFile plan for other formats you could fold that work in rather than maintaining a second vendor. Test your actual templates before believing this applies to you.

Cost comparison: PDFShift wins every row

PDFShift bills one credit per conversion for outputs up to 5 MB - a 14 MB PDF consumes three credits, so size your own numbers against your typical output. ChangeThisFile counts one conversion per call regardless of output size. Both figures below are list price as of 26 July 2026.

Per conversion that is $0.018 down to $0.0025 on PDFShift against $0.0193 down to $0.010 on ChangeThisFile - and the ChangeThisFile column only reaches its best rate if you consume the entire quota. PDFShift also discounts annual billing to ten months' price, which widens the gap further.

There is no volume at which this table turns around. If cost is what brought you here, you already have the cheaper vendor.

API mapping, if you are adding ChangeThisFile alongside

The last row is the only one that runs in ChangeThisFile's favour, and it is the reason to add it rather than to switch. Note that page-layout control has no equivalent at all: if your PDFs depend on margins, headers or footers, there is nothing to map them onto.

Code migration: BEFORE and AFTER

# BEFORE: PDFShift (Basic Auth, JSON body with HTML string)
import requests
import base64

PDFSHIFT_KEY = 'sk_your_pdfshift_key'

# Submit HTML string for conversion
resp = requests.post(
    'https://api.pdfshift.io/v3/convert/pdf',
    auth=(PDFSHIFT_KEY, ''),  # key as username, empty password
    json={
        'source': '
Invoice
Total: $100
',
        'landscape': False,
        'use_print': True
    }
)
with open('invoice.pdf', 'wb') as f:
    f.write(resp.content)

# AFTER (for simple HTML): ChangeThisFile
import requests
import io

# Write HTML to a buffer and convert
html_content = b'
Invoice
Total: $100
'

response = requests.post(
    'https://changethisfile.com/v1/convert',
    headers={'Authorization': 'Bearer ctf_sk_your_key'},
    files={'file': ('document.html', io.BytesIO(html_content), 'text/html')},
    data={'target': 'pdf'}
)
with open('invoice.pdf', 'wb') as f:
    f.write(response.content)

# For migrating other format conversions (images, docs):
# BEFORE: routing through PDFShift's general convert endpoint
# AFTER: same ChangeThisFile pattern above, change target format

Important: PDFShift accepts HTML as a string in JSON. ChangeThisFile requires a file upload — wrap your HTML string in a BytesIO buffer with the appropriate MIME type.

Auth migration

1. Get your CTF key: changethisfile.com/v1/keys/free. Free, no card.
2. Switch from Basic Auth to Bearer token: PDFShift uses Basic Auth with the API key as the username. Replace auth=(PDFSHIFT_KEY, '') with headers={'Authorization': f'Bearer {CTF_KEY}'}.
3. Convert JSON body to multipart: PDFShift accepts HTML as a JSON string. ChangeThisFile requires a file. Wrap your HTML in a BytesIO object or write it to a temp file first.
4. Remove PDFShift-specific parameters: landscape, use_print, margin, header, footer, sandbox — these don't translate to ChangeThisFile. For page layout control in generated PDFs, use CSS @page rules and print media queries in your HTML before converting.

Rollback plan

PDFShift plans are monthly — keep your subscription active during the parallel-run period:

1. Route conversions through a backend function that accepts a backend parameter. Switching back is a one-line change.
2. Compare PDF output side-by-side for your actual templates. This is the most important step for this migration — don't skip it.
3. If any template shows layout issues with ChangeThisFile output, route that specific template back to PDFShift. Some templates will be fine; others won't.
4. Cancel PDFShift only after validating output quality for your full template set.

Common questions

Will my invoice and report PDFs look the same?
No. PDFShift renders HTML with a browser engine; ChangeThisFile uses LibreOffice. Simple tables and text with basic CSS often come out close. Flexbox and Grid layouts, custom fonts loaded via @font-face, print media queries and anything rendered by JavaScript will not survive the trip. Convert your real templates and look at them before you decide anything.

Was I using PDFShift for image or document conversion?
You were not - PDFShift accepts HTML input only. If you have those conversions somewhere in your stack, they are running through something else.

Does ChangeThisFile convert PDFs back to HTML or DOCX?
Yes - PDF to DOCX, HTML, TXT and images are all supported routes. PDFShift cannot read PDFs at all, so this is genuinely additional capability rather than a like-for-like comparison.

Can I pass a URL like I can with PDFShift?
No. ChangeThisFile takes an uploaded file, so you fetch the page's HTML yourself and post that. Two steps where PDFShift needs one, and you inherit responsibility for anything the page loads.

What happens when I run out of quota?
PDFShift bills overage per credit and keeps working. ChangeThisFile returns HTTP 429 and stops converting until the next billing cycle - there is no overage on any plan. Size for your peak month.

What about webhooks?
ChangeThisFile's /v1/convert is synchronous, so the file comes back in the response and there is nothing to notify. Work longer than 180 seconds uses the asynchronous /v1/jobs endpoint instead.

If you are generating PDFs from HTML templates, stay on PDFShift. It costs less at every volume, gives you more free conversions to start with, absorbs spikes instead of failing them, and renders your CSS the way you designed it. We would rather tell you that than sell you a downgrade.

Come back to ChangeThisFile when the requirement changes shape - when you need to accept user uploads in arbitrary formats, pull a PDF apart into DOCX, or transcode media, none of which PDFShift can do. That is an honest reason to add a second tool. A free key is 25 conversions a month with no card, which is enough to find out whether the formats you need are covered.