Initializing... drag & drop files here
Supports: ODG
.odg is OpenDocument Graphics — the drawing format LibreOffice Draw and Apache OpenOffice Draw write, part of the OASIS OpenDocument family also published as ISO/IEC 26300. .tif is the other kind of object entirely: a grid of pixels described by TIFF Revision 6.0, finalised 3 June 1992 by Aldus Corporation, and still the file that document-imaging systems, journals and prepress workflows ask for. The three-letter spelling is the only thing separating .tif from .tiff; everything else on this page is about getting the render and the compression right.
.tif per drawing page, individually or as a ZIP. Files are uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours. No sign-up, no watermark.| Property | Value |
|---|---|
| Specification | TIFF Revision 6.0, final 3 June 1992 (Aldus; stewardship passed to Adobe in 1994) |
| Structure | A header plus one or more Image File Directories, so one file can hold several images |
| Compression tag | Tag 259 selects the scheme — the Compression Type dropdown is that tag |
| Baseline requirement | Baseline readers must handle uncompressed, PackBits and CCITT; JPEG-in-TIFF is an extension |
| Colour | 1-bit through 16-bit per channel; greyscale, RGB or CMYK, with optional alpha |
| Extensions | .tif and .tiff are the same format — a filename convention, not a variant |
| Browser support | None of the major browsers display TIFF natively; it is a print and archive format |
| Best suited to | Prepress, scanning and archival workflows that reject anything lossy |
The .odg is never handed to an image decoder. LibreOffice opens it as a Draw document, exports it through Draw's own PDF filter, and that page is rendered at 300 DPI before the TIFF writer sees anything — which is why the drawing's page size and object placement come through unchanged rather than being re-laid-out.
| Stage | What runs | What it produces |
|---|---|---|
| 1. Read the drawing | LibreOffice opens it as a Draw document | The original page geometry, in memory |
| 2. Export | Draw's PDF export filter (draw_pdf_Export) |
A PDF at the drawing's own page size |
| 3. Render | The page rasterized at 300 DPI | A4 lands near 2480 x 3508; US Letter near 2550 x 3300 |
| 4. Encode | TIFF writer at your Compression Type | One .tif per drawing page, numbered in order |
At 300 DPI with LZW, a full-page technical drawing is typically a few megabytes; the same page uncompressed is several times that, because NONE stores every sample verbatim. If a file has to fit a byte budget, drop the Image resolution before you reach for a lossy scheme — fewer pixels beats blurred edges on line art every time.
Because a drawing is the worst possible case for a photographic codec. JPEG-in-TIFF works on 8 x 8 blocks and spreads error around sharp transitions, which on a flowchart shows up as grey haze beside every black line and shimmer around small text. LZW and DEFLATE store the exact samples, and on flat artwork they compress it well precisely because there are large runs of identical colour. Photographic content is the only case where the default is the better choice.
.tif different from .tiff in any real way?No. Same specification, same byte layout, same readers — the shorter form dates from the era of eight-character filenames. What differs is what receiving software matches on: some scanning and archival systems accept only one spelling. That is the entire reason both are offered here, and why the twin page ODG to TIFF exists alongside this one.
Only if the drawing is genuinely bilevel — pure black and pure white, no greys. CCITT Group 4 is a bilevel scheme designed for fax and scanned text, and it produces very small files for that content. Applied to an anti-aliased drawing it has to throw away every intermediate tone, so edges that looked smooth become jagged. For a Draw file with anti-aliased strokes, LZW is the right lossless answer.
Two reasons. The render is 300 DPI, which is a lot of pixels for something you may only be viewing on screen, and TIFF's lossless schemes are older and less effective than PNG's DEFLATE-over-filters approach on flat artwork. If the file is for print, that size is the cost of the format. If it is not, either lower the Image resolution or convert to ODG to PNG instead.
Each page becomes its own .tif, numbered in page order, and the set comes back as a ZIP. TIFF itself can hold several pages in one file through multiple Image File Directories, but this route writes them separately. If a single multi-page file is a hard requirement, assemble the outputs with a dedicated multi-page TIFF tool, or send the drawing to ODG to PDF, which keeps the pages together by default.
Only under a lossless compression type. TIFF supports an alpha channel, but the JPEG scheme this page opens on does not, so transparent regions are lost there. LZW and DEFLATE keep it. If the destination cannot deal with alpha at all — and many prepress systems would rather not — put an explicit background rectangle in Draw so you choose the colour instead of a downstream tool.
Not as a drawing. The TIFF holds pixels: no shapes, no connectors, no live text, and no way to enlarge it without softening. Retouching is possible in any raster editor, redrawing is not. Keep the .odg as your editable master, and if you need a scalable hand-off use ODG to SVG, which preserves the real vector geometry.
Your .odg is uploaded over an encrypted connection, processed on our servers, and deleted automatically a few hours later together with everything it produced. Nothing is published, shared or reused, no account is required, and no watermark is applied. The ODG converter hub lists the other targets if TIF turns out not to be the one you need.