Which UniPDF version does UniHTML need?

github.com/unidoc/unipdf/v5. UniHTML imports v5 throughout, so your own program needs the same major:

import (
    "github.com/unidoc/unihtml"
    "github.com/unidoc/unihtml/sizes"
    "github.com/unidoc/unipdf/v5/common/license"
    "github.com/unidoc/unipdf/v5/creator"
    "github.com/unidoc/unipdf/v5/model"
)

v0.17.0 is the first UniHTML release on v5. Everything up to and including v0.16.0 imported unipdf/v4, so upgrading across that boundary means moving the UniPDF import paths in your own code in the same commit. No version of UniHTML works with both.

Why the majors cannot be mixed

Go treats unipdf/v4 and unipdf/v5 as unrelated modules, so importing both puts two copies of the library in your binary. Two things then go wrong at once.

The license state is per module. A key loaded through unipdf/v4/common/license is invisible to UniHTML, which reads v5’s, so Connect fails with invalid or no license provided even though you clearly set a key.

The types do not match either. GetPdfPages returns []*model.PdfPage from v5, and a v4 creator.Creator will not accept those. The compiler reports a type mismatch between two identically named types, which is a confusing error the first time you see it.

Moving a project from v4 to v5

Rewrite the import paths, then let the module graph settle:

go get github.com/unidoc/unihtml@latest
go get github.com/unidoc/unipdf/v5
go mod edit -droprequire github.com/unidoc/unipdf/v4
go mod tidy

Check what you actually ended up with, since a transitive dependency can drag the old major back in:

go list -m all | grep -E 'unihtml|unipdf'

Two unipdf lines means the mix is still there. go mod why github.com/unidoc/unipdf/v4 names whatever is still asking for it.

One API change that will bite

Creator.NewParagraph is gone in v5. Use NewStyledParagraph and set the text on it:

p := c.NewStyledParagraph()
p.SetText("Generated on " + time.Now().Format("2 January 2006"))

This shows up in UniHTML code more than you would expect, because drawing a paragraph next to converted HTML is the common reason to mix creator content with a unihtml.Document. See draw into a document.

What did not change

Nothing about how UniHTML behaves. The client API is identical across the move, and the behavior the guides describe was re-measured against a v5 build: the page size defaults still land on Letter, c.Draw still discards link annotations, and the margin and unit traps in margins are all still there, with the same numbers.

Everything UniHTML hands you is a *model.PdfPage, so whatever your pipeline does next, signing, encryption, merging, watermarking, is plain UniPDF v5 work from that point on.