Why photos come out blank or as OBJ boxes in a message export

Three different marks can turn up where a photo belongs in an exported conversation, and each has a cause of its own. An empty frame where the picture should be means the program that drew the document could not decode the image file. Small dashed boxes with the letters OBJ in them, scattered through otherwise clean text, are a placeholder character that was never removed. No photo at all, or a file name where the picture should be, means the file was not found. None of the three is a damaged conversation, and the fixes have nothing to do with each other.

Why is the photo an empty rectangle?

Because the engine that drew the page could not read the image file, and with iPhone photos the first suspect is HEIC.

An iPhone set to High Efficiency under Settings, Camera, Formats saves the new photos it takes as HEIF, the format behind .HEIC files; the other choice there, Most Compatible, saves JPEG. The setting covers new photos taken with that phone’s camera. A photo received in Messages is not governed by it; Apple says only that media shared through Messages may be converted to a more compatible format when the recipient’s device cannot handle HEIF.

Of the major browsers, Safari has decoded HEIC since version 17. Chrome, Edge and Firefox do not, and Mozilla’s request to add HEIF support has been open since 2017. An HTML export is opened in a browser, and a PDF made by printing a web page goes through a browser engine as well. Tested in Chrome 153 on Windows 10 on 2026-10-13, a picture the engine cannot decode does not stop the page or raise a message: where the layout gave it a size, Chrome leaves an empty frame with a small broken-image icon in the corner, and if the page gave the picture a text alternative, that text appears inside the frame. A frame showing a name that ends in .HEIC therefore names its own cause.

What to do depends on what you hold:

• An HTML export with a folder of files beside it: if the photos in that folder end in .HEIC, the files are there and only the browser cannot show them. Safari 17 or later opens them. On Windows, Microsoft’s Store listing for its HEIF Image Extension says the HEVC Video Extensions package must also be installed to view .heic files.
• A PDF: the frame is all the file holds, so no viewer setting brings the picture back. The fix is exporting again with a tool that converts HEIC before it draws the page.

ChatExport converts HEIC photos to JPEG before it renders the PDF or the HTML export, so the engine drawing the page is handed a format it decodes.

Why are there small boxes with letters in the text?

Because of U+FFFC, the object replacement character, which Unicode describes as a placeholder in text for an otherwise unspecified object. The message database puts one into a message’s text for each attachment, at the attachment’s position. A photo sent with no words has text consisting of that one character and nothing else.

Whether it shows depends on the font. Arial, Times New Roman and Segoe UI on Windows each carry a glyph for it, and in a test in Chrome 153 on Windows 10 on 2026-10-13 all three drew it as a small dashed box with OBJ inside. A program displaying the text in a font without that glyph may show it differently.

Each box marks the spot where an attachment was sent, and it can be read as exactly that: a photo or file belonged there. Removing it is the exporting tool’s job, done before the page is drawn, keeping a caption’s words and leaving an uncaptioned photo with no text at all. An export already made keeps its boxes, so the fix is exporting again with a tool that strips the character.

Is a message that shows only an OBJ box an empty message?

No. A message whose text is nothing but that character was sent with an attachment, and the attachment is recorded in a separate table, not in the message row. An implementation that strips the character, finds no text left and treats the message as empty can lose the photo from the transcript as well, so the conversation reads as though nothing was sent at that moment. ChatExport keeps such a message whenever an attachment row stands behind it, and leaves out only a row that has the placeholder and no attachment at all.

Why would an export have no photos at all?

Because the exporting tool did not find the files, either through how it looks them up or because they are not in the backup.

Inside an iPhone backup, every file is stored under a name computed from a domain and its path: the SHA-1 of the domain, a dash and the relative path. The message database sits in HomeDomain. Its attachments are named under MediaDomain. An implementation that computes attachment names with the database’s domain gets well-formed names that match no file, every lookup comes back empty, and the result can look exactly like a backup without attachments while the backup holds them.

To tell the two apart, open the same backup with a second tool. If its photos appear there, the backup holds them and the first tool’s lookup is at fault. If no tool finds them, the files are not in this backup.

Can a photo be gone even when the message is there?

Yes. The message database keeps a row for each attachment that names the file, and that row can be present while the file itself is not in the backup. In that case ChatExport prints the file’s name with the words “missing file” where the picture would be, so the document records that a photo was sent at that moment. Exporting the same backup again will not bring the file back.

The route from a backup to a finished document, photos included, is in the complete guide to exporting iPhone messages to PDF. How each attachment type lands in each format, the attachment index included, is in export iPhone messages with photos and attachments.