I can see how to turn this behavior off in a previous question at How to set Preview to start on the last viewed page?

But what file is/was storing this persistent data about the last page read of a PDF in Preview ? I have experimented with deleting many cache, plist and other files associated with the Preview app, even its bookmarks and those in ~/Library/Containers and none of them seem to stop it remembering the last page read in a PDF document.

Can someone please name the specific file where this information is stored?

Thank you. I'm still on Lion btw

2 Answers 2


I’ve got it. I think. Took me a long time but I think I have worked out what’s happening. Hopefully this might be helpful to someone else.

First of all I noticed locking the file in the Finder seemed to stop Preview remembering a different page. So if I opened the PDF on page 1 and then scrolled to page 10 it wouldn’t remember the PDF was on page 10 anymore when the file was closed then reopened. That was the first clue.

I then used fseventer which monitors file changes in real time and I was surprised to see that opening a PDF in Preview, scrolling to a different page and then closing the PDF updated the file itself. It doesn’t literally register a time change in the Finder, the date stays the same, but fseventer threw up the clue ‘Modified xattr’.

Ok, I dimly remembered some mention of this feature called extended attributes from years back, it seems to function like yet another kind of metadata but that’s quite separate from ‘normal metadata’, and now I'm reading was a replacement for the old resource forks in OS 9. Running $mdls (used for normal 'metadata') in Terminal won’t show extended attributes.

You have to use the command $xattr to see these attributes.

When I ran $xattr /Volumes/mydisk/mypdf.pdf I got this:

/Volumes/mydisk/mypdf.pdf: com.apple.Preview.UIstate.v1: And another line about a quarantine bit

You have to do $ xattr -lv to see the full data of these extended attributes. It produces a blob of hexadecimal output for com.apple.Preview.UIstate.v1.

So I ran $ xattr -lv /Volumes/mydisk/mypdf.pdf

And copied the output. Then I opened the PDF in Preview, changed the page and closed Preview.

Then I ran $ xattr -lv /Volumes/mydisk/mypdf.pdf again

And then compared the blobs of hexadecimal output for com.apple.Preview.UIstate.v1, which were different between the two occasions.

The final test was to delete the extended attribute data:

$ xattr -c /Volumes/mydisk/mypdf.pdf

And that’s it! It’s back to page 1 when you open it in Preview

It appears the last page viewed of a PDF is stored in these extended attributes. I’m so happy!!


Using filemon from the book "Mac OS X Internals - To The Apple's Core" it appears the only Preview related file that's modified if all I do is open, e.g. a .pdf document in Preview and close it to a different page is the com.apple.Preview.ViewState.plist file located at:


The file is not what I'd call in friendly human readable format as it's primarily a list of UUID's which contain a Timestamp and Data key however the Data key is not in a friendly human readable format although the Timestamp key is.

I was however able to watch the Timestamp value change on different UUID's as I opened and closed recent documents when I closed them on different pages then was opened. So while it's the right file, not sure how much use the file will be to you.

  • Appreciate the serious answer, but I can't replicate this here. Although what you say sounds like a good fit, I don't have the file /Users/$USER/Library/Containers/com.apple.Preview/Data/Library/Preferences/com.apple.Preview.ViewState.plist and the behavior is still going on. There is somewhere else this data is being stored. The mystery continues...
    – lrobes
    Jul 5, 2015 at 21:25
  • Sorry, I did that on Mountain Lion, hadn't had my coffee yet. Will look into a Lion build to tomorrow and get back to you. Jul 6, 2015 at 0:34
  • Understood. Look forward to any further insights.
    – lrobes
    Jul 6, 2015 at 11:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .