Initializing... drag & drop files here
Supports: PUB
A .pub is a Microsoft Publisher document — a multi-page print layout with text frames, linked artwork and a physical page size. A .jfif is a JPEG. Not "a bit like a JPEG": the same baseline DCT image data that a .jpg holds, under a different four-character extension. This page rasterises each Publisher page and writes it out with that extension, which is what you want when a submission portal, an asset importer or a records system asks for .jfif by name and rejects everything else.
Timing matters here. Microsoft has published an end-of-support date for Publisher: October 1, 2026 for Microsoft 365 subscribers and October 13, 2026 for the perpetual-licence versions. Getting artwork out of .pub while tools still read the format is a real deadline, not a marketing line.
A .pub is a layout, not a picture, so there is nothing to "re-save". On our servers the file passes through three distinct stages, and each one determines something different about the result.
| Stage | What runs | What it fixes | What you control |
|---|---|---|---|
| 1. Import and lay out | LibreOffice opens the .pub through its Draw component (the libmspub import filter) and exports the layout to PDF |
Font substitution, text reflow, whether the layout survives at all | Nothing on this page — the fidelity comes from the import filter |
| 2. Render pages | Each PDF page is rasterised at a fixed 300 DPI | Pixel dimensions: a US Letter page lands at 2550 x 3300, A4 at roughly 2481 x 3507 | Nothing — there is no DPI box on this converter |
| 3. Encode | libvips writes each rendered page as baseline JPEG under the .jfif name |
File size and visible quality | Quality Preset, Specific file size, Image resolution |
Two consequences follow. One file comes out per page — a four-page newsletter downloads as a set of four .jfif images in page order, not one stacked file. And the starting pixel size is decided by the page's physical dimensions rather than by anything you choose, so "Image resolution" is the control that scales it down afterwards.
.pub onto the page or click "+ Add Files" to browse. Several publications can be queued and they all run with the same settings.We rendered a 2550 x 3300 Letter page — black body text on white with one flat colour block, the shape most Publisher flyers actually take — and pushed it through the same libvips JPEG writer this page uses at every rung of the ladder:
| Quality rung | Output size | Chroma handling |
|---|---|---|
| Highest | 154,775 bytes | 4:4:4, full colour resolution |
| Very High (preselected) | 141,324 bytes | 4:4:4 |
| High | 134,428 bytes | 4:4:4 |
| Medium | 76,430 bytes | 4:2:0, colour subsampled |
| Low | 72,721 bytes | 4:2:0 |
| Very Low | 70,367 bytes | 4:2:0 |
| Lowest | 68,593 bytes | 4:2:0 |
The absolute byte counts depend on what is on your page, but the shape of that curve does not. Nearly all of the saving happens in one step — between High and Medium — and that is exactly the step where the encoder stops storing colour at full resolution. On a photograph you would barely see it. On coloured headings, thin rules and small type it shows up as a faint haze along the edges. Below Medium you are paying real quality for almost no further saving, which is why the honest advice on a text page is: stay at Very High and reduce the pixel dimensions instead.
| Property | PUB (Microsoft Publisher) | JFIF |
|---|---|---|
| Kind of file | Binary, proprietary page-layout document | Single still raster image |
| Origin | Microsoft, first released 1991 | JFIF 1.02 published 1992; later ITU-T T.871 (2011) and ISO/IEC 10918-5 (2013) |
| Payload standard | Undocumented Microsoft layout format | JPEG itself — ITU-T T.81 / ISO/IEC 10918-1 |
| Pages | Many pages in one file | Exactly one image per file |
| Text | Live, editable, searchable in Publisher | Flattened to pixels |
| Transparency | Supported in the layout | None — JPEG has no alpha channel |
| Colour depth | Whatever the layout references | 8 bits per channel |
| Opens in | Publisher; partially LibreOffice Draw | Every browser and image viewer |
| Status | Support ends October 2026 | Stable; the same bytes as a .jpg |
No. JFIF is the interchange convention that says how JPEG-compressed data is packaged for exchange, and it is what almost every .jpg on the internet already follows. A file written by this converter is a baseline JPEG whichever extension you give it: same start-of-image marker, same DCT coefficients, same Huffman tables. Renaming a .jfif to .jpg changes nothing but the four characters after the dot, and JFIF to JPG will do the rename properly if a tool insists on doing it by conversion.
Because JFIF, like JPEG, holds exactly one image and has no page structure at all. Each Publisher page is rendered independently and encoded as its own file, numbered in page order. If you need every page kept together in one openable document, PUB to PDF is the right target — that is also the format Microsoft points to as the migration path before Publisher support ends.
Because the render happens at a fixed 300 DPI and the Conversion Quality (DPI) box does not appear on this converter. Work backwards from the page's physical size instead: US Letter at 300 DPI is 2550 x 3300 pixels, A4 lands near 2481 x 3507. Both are already generous for screen use and for printing the page at its original size. To make the file smaller, use Image resolution — Preset Resolutions, Resolution Percentage, or an explicit Width and Height.
Pixel dimensions, not quality. Setting Image resolution to a Preset Resolution or applying a Resolution Percentage cuts the file dramatically with far less visible damage than dropping the Quality Preset, because a text page degrades gracefully when it shrinks and badly when it is crushed. If the form enforces an exact byte ceiling, switch Image Compression to Specific file size, enter the limit, and leave Auto Scale on so the encoder is allowed to reduce dimensions to reach it.
No. Every image target flattens type into pixels, so the words cannot be selected, searched, restyled or copied out afterwards. That is inherent to raster output rather than a limitation of this tool. If you need the text to survive as text, convert to PUB to PDF first and export onward from there.
Single-page flyers, certificates and straightforward newsletters generally come through cleanly. The risk sits in fonts and links: .pub is a proprietary Microsoft format, so a third-party import filter substitutes any typeface that was not embedded in the file, and externally linked images that are no longer next to the .pub cannot be pulled in. Heavily layered designs with unusual effects are the most likely to shift. Spot-check anything complex, and if you need a print-exact result, export it from Publisher itself while you still can.
It is now white. JPEG has no alpha channel of any kind, so the transparent area is composited onto the page background before encoding, which is also how the publication would print. If you genuinely need transparency preserved, PUB to PNG keeps an alpha channel, and PUB to WebP does too at a smaller size.
Not from this page — a JFIF is a fixed grid of pixels and can never be scaled up cleanly. PUB to SVG is the vector-shaped route on this site, and that page explains what its output actually is and where it falls short. The dependable way to keep a Publisher page resolution-independent is PUB to PDF, which carries the layout's own vector geometry and its text rather than any approximation of them.
It is uploaded over an encrypted connection, rendered on our servers and deleted automatically after a few hours, along with the images it produced. Nothing is shared or made public, there is no sign-up and no watermark. Publisher documents are usually small by modern standards, so the encode rather than the transfer is the slow part; a very long publication takes longer mainly because every page is rendered separately.